tdc001 thorlabs

[Paige5]

Thanks Kyle; I'll try it!

[Paige5]

Hello.

i have researched even structures, but I am obviously missing something here. I think I need some sort of initiator for the event structure but am unsure how to achieve this. I know this is simple stuff but I'm still a beginner with Labview and these specific property nodes for the TDC001. I want the code to:

1) have the motor move the actuator in one direction at a specified velocity until the switch is pressed (later the case structure/switch will be governed by a load cell meeting a specified load)

2) have the motor wait a specified time

3) have the motor move the actuator in the OPPOSITE direction at a DIFFERENT specified velocity until a different switch condition is met

I have the first bullet correct and working in the VI called "Working Test Code". I am trying to add the 2nd and 3rd steps in the file "working test code 3316" attached with an event sequence and cannot get the program to run without first pressing the Boolean for each event. Please, any suggestions would be great! Also remember that the boolean are just place holders for switch conditions that will be controlled by other parameters like load cells readings. 

Thanks for all the help!

[Kyle97330]

This is the sort of situation that what's known as a "producer/consumer" program type is good for.  See this NI white paper on the subject.

Basically you have an event loop at the top that processes button presses by changing them into instructions, and a queue loop at the bottom that does those instructions in order.

The queue loop is where you put all of your commands and the commands can come both from the event loop and from other parts of the queue loop.  I won't write your code for you but I do have a working system with 4 Thorlabs motion controllers all running at the same time that uses what is effectively this format and it works.

[Paige5]

Hello,

I am learning a lot of great things with your advice! So, I am running a producer/consumer loop in the regular data structure (not the event structure producer/consumer loop). This is because when I attempted to use the event structure, I had trouble with the same sort of "initiation" that was missing in the previous regular event structure. I want the motor to immediately move once the program is started. 

The code is running, so far, the way I would like it too, except for one thing. I want the queue to be cleared when the "true" case is met in the "no error" section of the consumer loop. The dequeue to the flush (I have also tried the "realease") queue element is a technique that I have seen used to stop the producer/consumer loop associated with the input code. However, when I use highlight execution, my data is not moving out of my consumer loop. Do you (or anyone!) have any idea why this is happening? Or how I can address the problem?

Many, many thanks again to your suggestions, Kyle. 

[RavensFan]

It is very, very odd that your queue element is the reference for the motor control itself.  That reference value never changes for the life of the VI.

Typically the queue elements are going to be either a command, data, or a combination of command and data travelling from the producer to consumer.

I suggest rethinking yoru architecture.

[Paige5]

Hi,

I see what you are saying here. Shouldn't my element have to match the original queue data type? The queue data type was defined by the start ctrl of the motor in the beginning, so I figured the element could be derived from another motor control element. 

Am I correct in this thinking or can I use a different data type for the "element" section of the queue controls?

Thanks!

[RavensFan]

Using the motor control reference to define the queue at the beginning was the mistake.

You can use whatever datatype you want to define the queue.  A common queue datatype is a cluster that contains an enum and a variant.   The enum would be a list of different commands.  The variant would hold the data that is relevant to the command being sent .  The advantage of the variant is that it can hold any kind of data so if one command is something that sends a string, it can hold that.  If another command needs a boolean, it can hold that.  The disadvantage is that at the consumer end you'll have to convert the variant back to data in each case of your case structure.

If all your commands used a single type of data such as a numeric, you can have an enum and the numeric in the cluster.

[Paige5]

Hello,

I tried your suggestion, but the more I work with the producer/ consumer, the more I think it may be wrong for my application. I am not doing any intense data processing or anything, it is simple code that just needs switch cases to control the majority of the code. 

The producer/consumer videos and other references brought my attention to notifiers, which I think may be more applicable the my end goal. However, it seems that once the "wait on notification" sub vi receives its notification, the while loop is only running once? I'm not exactly sure what is happening, but the data flow just stops after its initiated.

If anyone has ideas as to why this is happening or good references on notifiers, that'd be aweseom! Thanks!

[RavensFan]

References on notifiers:

1.  Context Help

2.  LabVIEW Help

3.  Example Finder

4.  Messages in the forums

The purpose of notifiers is exactly what the name of the one function says.  "Wait on Notification".  When you want the code to wait until it gets notified to continue by some other part of your code.  If you have any code that shouldn't be help up, then it shouldn't be in the loop that has a Wait on Notification.

Having a notifier may not be necessary for your application.

Pretty much all the advanced LabVIEW architectures are based on one of three concepts, or some combination of them.

1.  State Machine - When you have a sequence of steps you need to follow, but what the next step is would be dependent on the state or activities that happened in the previous step.  Sometimes returning to the same step is a valid option.

2.  Event-based - When you need code to wait on events to happen then react quickly to them.  User presses a button?  Changes a number?  Hits the Stop button?  Detect that and command things to happen.  It might be telling the state machine what the next step to handle is.

3.  Producer/consumer - When you have basically different activities that need to run somewhat independently.  Perhaps one loop is acquiring data and passes that to another loop to log it ot a file.

[Paige5]

Hello,

Thank you everyone for the help! The notifier vi is working.

I had to take the "wait on notification" out and put it in its own while loop, wiring its true value to the stop condition of that loop and then over into the next loop case structure (see the old vi I posted). I hope this helps others who are trying to do similar things with the TDC001 motors.

Thanks again!