LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stop/Start DAQ-mx acquisition with boolean

Solved!
Go to solution

Thanks for posting the VIs, I am busy finishing an end of the year report now, but will not at in more detail when I have some time. However, it would help alot if you explain in simple words exactly what you want to do wand where things start.

 

For example:

I am reading two digital lines, extend and retract, they both start at low. When extend changes to a high state I want to ... Does extend stay in a high state until ...

 

Cheers,

mcduff

Message 11 of 37
(916 Views)

Please don't let me distract you from your important work, my problem isn't time sensitive and I appreciate your input but please don’t feel pressured.

The arm movement is fairly simple, a motor the can either extend or retract the arm, a switch at each end  tells  the motor where to stop. On initialisation the arm extends until it triggers the extension end stop switch, it then dwell for n secs and then retracts until the retraction end stop switch triggers. The routine then repeats I’m looking to measure current and temperature only when the motor is working.

0 Kudos
Message 12 of 37
(911 Views)

Don't worry about it, really don't want to write the report.

 

Right now from your example it is hard to tell whats going on. This is what I am looking for,

  1. The digital line 1 starts in a low state, when the arm is extended to its limit, the digital line goes to a high state.
  2. Once the arm starts retracting, digital line 1 goes to a low state.
  3. When the arm is fully retracted digital line 2 goes to a high state.

Am I making sense? In order to help you, I need some specifics about your setup and what transitions it is going through.

 

mcduff

Message 13 of 37
(908 Views)

Hi mcduff,

Yes your description makes perfect sense, imagine a meter rule, move a slider out towards 1000mm, at the 1000 mm the extended limit switch goes from low to high, the slider stops for n secs, then slider reverses direction the extended switch goes low. At 0 mm the retracted limit switch goes from low to high and the system for n secs and the motor reverses direction again and the retracted limit switch goes from high to low. Imagine a simple plc.

I just need to measure the motors performance/temp etc

 

Regrads

 

0 Kudos
Message 14 of 37
(904 Views)

With due apologies to mcduff for having peeked at the code before responding...  (Smiley Wink  msg #6)

 

You've got the basic functionality in place for your limit switch monitoring loop and your motor activation loop.   It seems to be generally working.  You also have all the info you need to know when to signal to your 3rd DAQ loop about when to start and stop acquiring.

  

A few specific suggestions:

1. Limit Switch Monitor loop

Use a shift register to store the previous state.  Only alert the other loops when there's a transition.  I would send the limit switch states to the actuator loop with a Notifier rather than a Queue. Since (T,T) is probably an illegal value for the 2 limit switches, initialize your shift register to (T,T) so that the very first DAQmx Read looks like a change and helps initialize the other loops.

 

 2. Actuator state machine loop

Receive data via Notifier rather than Queue.  Consider only "listening" for a Notifier in your "Extend" and "Retract" states as your dwells are simply fixed times that pay no attention to the limit switch data anyway. 

   Right now you do DAQmx digital writes of the same data repeatedly for as long as you stay in any of your states.  You should only write once when you first enter that state.  Or perhaps just *before* entering that state (either by making a new dedicated state for the writes, or including them in the logic that causes the state transition).

  Your state machine iterates faster than necessary, in part because you used a Queue even though you only care about the present state of things.  A Notifier is a better choice for this.  And you can use the timeout input to "Wait on Notification" to make sure you respond to limit switch transitions without needing to spin in what's effectively a polling loop.

   This is the loop where you know when you're about to start and stop the actuator.  So from these same places, you can let the DAQ loop know when to start and stop.  Again, a Notifier would be a better choice than a Queue here.

 

3. DAQ loop

   This could be a state machine with key states being "Idle" and "Acquire".  In the "Idle" state, you can simply wait indefinitely (or repeatedly) for a "True" notification that will mean "start acquiring".  In the "Acquire" state, do the DAQmx Read first, and then check for a notification.  In this case you'd use a 0 timeout.  In both cases you'd probably want to set "ignore previous" to False.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 15 of 37
(897 Views)

Here's my advice. Now that Kevin is following this thread, follow his advice.

 

Attached is a quick, simple, and INCOMPLETE take on what you could do.

It is in 2016 version, and I think you could get a way with one loop. This loop shows how DAQmx events work, I do not have the hardware, have not tested, so there will be bugs. It uses a riff on the State machine you used, except JKI, but you do not need it installed to run the project.

 

State machine spins up and

  1. Initializes DIO tasks
  2. Reads initial DIO lines
  3. Registers for change of state lines
  4. Right now only updates the indicators when the state changes, you can add to this
  5. closes the loop when you exit

If no errors with your device hooked up, experiment and see what happens when your lines go from high to low, low to high, etc. Once you understand that, you can start to add to it.

mcduff

Message 16 of 37
(890 Views)

Hi,

Thanks for your interest – one thing I neglected to mention is the occasional odd behaviour of the actuator.

Due to the unit selling at an attractive price point, when mounted vertically and under load it can be pulled past the limit switch. So when extending limit switch goes momentary high and then low at the park position. The Extended limit switch is then triggered momentary as the arm retracts.

More by luck than design the existing design seems to ignore the fun design trait. I will have a play with some of the other suggestions as my lack of experience makes it difficult visualise

0 Kudos
Message 17 of 37
(881 Views)

Hi mcduff,

Thanks for the project – I’ve not come across the JKI state machine before and it looks useful. Plus kudos for putting it context, I’m in with a chance of understanding it.

Regards

0 Kudos
Message 18 of 37
(872 Views)

Look it over see if some makes sense, if it works, etc.

It is an example of a DAQmx event, so when it goes high to low, it triggers an event, we can add in the data recording later, after you understand what I did and/or what i did wrong.

 

mcduff

0 Kudos
Message 19 of 37
(867 Views)

Hey Simon-lee,

 

Please allow me one comment as well: What kind of hardware are you using? Could not read it from your code, as you (which is good) gave your hardware devices meaningful names.

I am asking, because you might be able to use DAQmx's Pause Trigger capabilities. If I understand correctly you need to acquire data whenever your actuator is moving. And basically you move it by outputting T/F to it. Why not use this output as a trigger for acquisition as well? See sections F and G in NI-DAQmx Data Acquisition Triggering Techniques Using LabVIEW.

 


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
Message 20 of 37
(854 Views)