stacked sequence structure

[John_P1]

Hi Leanne,

Try removing the DAQmx Timing node as mentioned above.  I don't believe the problem is the feedback node but rather the DAQ buffer accumulating samples (1000/second).  You will be reading the samples in the order they come in, so as the program runs your loop is lagging behind the data acquisition (eventually it will error out with a buffer overflow).

When you add the actuator code back in, this includes a rather long delay in software, during which you are not calling DAQmx read and samlpes are accumulating in the buffer.  Since you are only reading one sample at a time, the loop cannot keep up with the data acquisition (i.e. it does not run at 1000 times / second). 

You should not need to use a buffer for this application, since we are trying to control an output based off of a single point of data.  We always want to use the most recent sample.

-John 

[leannee]

That worked!  Thank you!  Thank you! 

I'm apologize for skipping over your previous advice, it's so easy to get caught up in one thing when you're trying to debug in a language you don't know how to use.  I really appreciate your patience.

Thanks,

Leanne

[John_P1]

Hi Leanne,

Not a problem, glad everything is working better for you!

In retrospect my last post was quite wordy--I should have gotten to the point a little sooner!

-John 

[leannee]

Hello John P,

We're still having trouble working with the execution speed of the program.  Although it is significantly improved right now, there is still too much of a lag between the motor's stop/go command.  This would not be a problem for us if the lag were consistent because we could just correct for the error in our program; however, it is not.  We figured this out by placing elapsed time sub-vi's upstream and downstream of the motor's case structure and upstream of the actuator's case structure.  From this we were able to see that the motor's case structure takes varying amounts of time to execute during each iteration of the while loop.  We're talking about 0.1 sec the first iteration and then variations of up to 0.9 sec.  However, the execution times appeared to be random and did not show an increasing trend, which is what I would assume should happen.  Is this an inherent issue with using a case structure?  Do you have any recommendations for approaching this obstacle?

Thank you for your time,

Leanne     

[John_P1]

Hi Leanne,

Could you post the code as you have it currently?

The underlying issue is that you are using non-deterministic software to control the system and so you are at the mercy of the OS.  A 800 ms difference is quite a lot, but perhaps the issue is that the case structures are running in parallel and so different loop iterations result in different cases which take different amounts of time to execute.  I am not sure how beneficial it is to measure the amount of time it takes to exectue a certain section of code when other tasks are going on in parallel that change from loop to loop. 

You probably don't want to be running the case structures in parallel, this was my mistake in the screenshot a few posts back.  It sounds like you wanted to write data to the motor before the actuator, so you should wire an input to the actuator case structure that would force it to run after the motor case structure (e.g. use an error wire from the DAQmx Write for the motor and wire this into the case structure).

What are the ramifications of the problem in hardware?  That is, what is the cost of a delayed start / stop command.  I have gathered so far that you are using a light sensor to start/stop a motor, and when the motor is stopped trigger an actuator.  Is the motor overshooting the light source because the stop signal is not read quickly enough?

-John 

[leannee]

What we have is a lazy susan like device with 24 holes cut around the perimeter, in each of which a lotion bottle sits.  As the motor rotates this disc around based on which photosensor is activated by the user's input for desired bottle number, it should stop when an LED comes around to the activated sensor, indicating the the specified bottle has reached its location.  After reaching its location the actuator fires upwards, depressing the bottle against a L-beam that sits above the pump top on the bottle.  So if the motor does not stop in the desired location the actuator will not hit the bottle and instead press up against the acrylic that the lazy susan is made out of because it falls between two of the holes and if we let the actuator fire the needed length it could damage our device.

Thank you   

[John_P1]

Hi Leanne,

I'm not sure if you will be able to get the level of control you need with the 6008.  The 6008 does not support Analog Triggering or Triggered Digital Output.  Because of this, we must rely on software to process the samples and output to the digital lines.  Combined with the relatively high latency of USB, this makes the situation less than ideal.

There may be some optimizations you can make within your code (for example, you could call DAQmx Write only when the value needs to be updated), but I cannot guarantee that this will improve the performance to a satisfactory level.  You might consider the Master/Slave design pattern so you can have your input and output running in parallel threads.

Ideally you would want to be doing all of the control without dependance on software processing.  I would look into using an external Comparator circuit to control the motor (since the USB 6008 does not have one built-in).

-John 

[leannee]

Hello John P,

Thank you for all your help!  Unfortunately my team and I are graduating so our work on the project has come to a close.  Right now we're working on truning the project over to our principal investigator and making recommendations for future work.  Would you then recommend that he purchase a device suchs as the USB -6218 or the PCI-6224?  They offer digital triggering, would that help to improve the positional accuracy as far as software and data acquisition hardware are concerned? 

Leanne     

[John_P1]

Hi Leanne,

Congratulations on graduation!  The project should run much more smoothly on a board with analog triggering and hardware-timed digital I/O.  The 622x boards fit this description (621x boards lack analog triggering capabilities and do not have hardware-timed digital I/O, although they do have fully functional counters).  Unless you need the higher channel count of the 6224 I would look into the 6220, or possibly the 6221 if you think you may need analog outputs in the future.  The 6221 also comes in USB form.

You can also have your principal investigator contact NI for help in making a decision, we have quite a few products that would work depending on the specifications you are looking for.  For instance, the 625x boards and 628x boards have higher sample rates and more accurate measurements.  We also have a wide range of control products that utilize LabVIEW FPGA, although this would be a big step up from a DAQ device and may be a bit overkill in this situation.

From the description of your project I think one of the M series boards mentioned above should work, but I would certainly recommend to call us before making a purchase to discuss all available options.

-John