05-25-2017 07:14 AM
Hello Everyone,
Thank you all for the help so far! I am learning a lot. Still on stabilizers and back to the Forum for more help...
I will post everything so it helps others later.
This is part 3 of this simple VI to Ramp Up and Down my slider. Part of a much larger project.
This is part 3 of a simple VI to Ramp Up and Down my slider. Part of a much larger project I'm working on.
This works very well, nice and smooth.
I would like it to have a button that tells the motor to STOP or RETURN to ZERO.
I am sat staring at the .VI thinking "I have no idea".
Any shove in any direction will help if anyone can help.
I have introduced an Initial Position into the mix, thinking this might be what I have to call?
As always the .VI is attached for others.
Regards,
Mike
The previous task is here: http://forums.ni.com/t5/LabVIEW/Obtaining-data-from-line-on-graph-Is-this-possible/td-p/3633416
05-25-2017 07:17 AM
Yes, the .VI, as promised, is now attached.
05-25-2017 09:17 AM
I see you still aren't using a state machine of some sort. While your program is still relatively small and simple, do yourself a favor and download the JKI statemachine from VIPM and learn how to use it. I've created a starting point to get you going in that direction. You'll need to get the code from VIPM before running this because there are some helper VIs that are not included here.
The first state called is Macro:Initialize. Navigate to that state and follow the flow. Within that state, 5 more states are added to the queue. The fifth state added is a macro that I created for initializing your motor. If you navigate to that macro, it adds two more states to the queue (Set Acceleration, Set Deceleration). Within those states, you can add the code necessary to perform those tasks.
You can create additional macros that accomplish tasks by calling a series of commands, one after the other. When adding states to the queue, you'll need to conscience of the fact that states can be added to the front of the queue or to the end of the queue.
Try to avoid using long running while/for loops within a state. Instead, call the same state again and again with some logic to decide when to stop calling it. In those scenarios, you'll probably also want to add a call to the IDLE state so that your UI stays responsive and events are handled.
05-25-2017 11:08 AM
I'm here.
At the beginning!
I know nothing again; 🐵
YouTube!
M
05-25-2017 12:14 PM - edited 05-25-2017 12:15 PM
The problem with your VI is you don't have a good, logical place to add code that tells the motor to stop and go back home. This is typical with beginners and it's why the experts will also says "pick an architecture that makes sense for your app" because if you don't, you'll end up with code that is hard to maintain and add functionality. However, a state machine does have a logical way of doing this.
It appears that you have downloaded the JKI toolkit. Put the VI into "Highlight Execution" mode (light bulb) and step thru the execution sequence to see how it works. Play with it for a while. Experiment. You'll be glad you did.
05-25-2017 12:16 PM
Will do.
Trying to get the editor working. Nothing when I right click.
Working on that now. I'm in a bar drinking beer downloading stuff.
;o)
05-25-2017 12:30 PM
Having trouble instaling it so it works. I don't get the editor.
Should be above the Visible Items menu shown below.
Why do software makers claim to make things easier when it is harder?
05-25-2017 01:07 PM
05-26-2017 05:12 AM
+1 for the state machine. It will make life much easier in the long run, and you get to learn something new
As for the beer. My rule is code drunk, but debug sober.
Deceased
05-26-2017 05:31 AM
;o)
I'm on it!
Learnng!