11-03-2018 02:10 PM
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
11-03-2018 04:35 PM
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.
11-03-2018 04:50 PM
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,
Am I making sense? In order to help you, I need some specifics about your setup and what transitions it is going through.
mcduff
11-03-2018 05:16 PM
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
11-03-2018 06:29 PM - edited 11-03-2018 06:30 PM
With due apologies to mcduff for having peeked at the code before responding... ( 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
11-03-2018 08:01 PM
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
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
11-04-2018 03:47 AM
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
11-04-2018 10:48 AM
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
11-04-2018 11:38 AM
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
11-05-2018 02:11 AM
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.