LabVIEW
Error messages
@cbutcher wrote:
@labview99 wrote:
I try to explain what I want to do.When the VI in the state "Mandar a posiicon" verifies if the cylinder has reached its position, and if it has not arrived it will go to the "error" state.
So here I'd like to mention again what I said about naming states. Is it really an "error" if the position is not reached immediately? Probably there is some time needed to complete a movement, and if you go immediately to measure, then error, you will probably spend lots of time in the "error" state. Maybe this is a good description in your opinion, maybe not.
I'd be tempted to choose different naming to indicate you're waiting, not necessarily that something has gone wrong (and maybe go to an error state after some time, if you still didn't reach the target position).
He has LOTS of waits inside that vi that he broke into two. This is why I have encouraged him to move all of that into a proper state machine. His "Mandar a posiicon" does a lot more than just tell it to move to position. In this case I do believe his "error" state is that it didn't reach the position, though I, like you, would use different terminology (probably something like Position reached?). The big problem here, though, is in the failure to properly break the code down into individual states. I don't know if you looked at that original subvi but it contained a flat sequence structure that stretched across multiple screens.
@labview99 wrote:
If I put all the code in the state machine the subVI is not worth anything, I have made the subVI so that at the end on the front screen it does not have a lot of indicators and controls
Why do you need a lot of indicators and controls? If you're calling the subvi then you're giving values to the controls and reading them from the indicators. Why can't you do the same in the state machine? Yes, the subvi is worthless in this case. That's why you need to move it into the state machine.
@labview99 wrote:
The problem is that if the cylinder does not reach the position, it is usually because someone has invaded a safety barrier on the cylinder. Then you have to rearm the machine and then if I change a value of the array of the subVi that I have told you, the movement of the cylinder resumes. Because of that I would like to acces to the array.
Please draw out a state chart showing the complete process. This includes what happens if the cylinder does not reach the position.
@labview99 wrote:
The problem is that if the cylinder does not reach the position, it is usually because someone has invaded a safety barrier on the cylinder. Then you have to rearm the machine and then if I change a value of the array of the subVi that I have told you, the movement of the cylinder resumes. Because of that I would like to acces to the array.
Ok. So I believe johntrich has mentioned this a few times, but essentially it seems like your goal here is to enable your VI to continue safely after a safety barrier is tripped/triggered, once it is rearmed again. Is that right?
If so, you probably want a series of states like the following (this is just my imagination, you might know better based on the actual equipment/experiment):
- Moving to a position (happily). Set the target value for the motor/cylinder, everything good (let's say the target is 10)
- Check the position. Not there yet. We're at position=5.
- Check the position. Not there yet. We're at position=7. It's not the same as before, so let's keep waiting.
- Check the position. Still not there. Position = 7. Hmm... maybe we check one more time? But mark this as a "first failure", perhaps.
- Check the position. Still at position = 7. Probably something went wrong? (If you have a sensor that you can read for the barrier, you can check this much earlier)
- Go to some error state. Check if the system is "rearmed". Not rearmed.
- Wait for rearm. Check if rearmed? Nope...
- Wait for rearm - yes, rearmed.
- Move to position (where are we supposed to be?). Set target position = 10. So here we can consider an index into an array, that we still haven't incremented, because we never reached the position.
- Check position. Position = 10. Yay, made it. Increment the array index.
- Do some experimental measurement? I don't know...
- Move to position. Index is now 1 (started at 0). So use Index Array with index = 1 to get the next position. Set that as the target position. Go to "Check position" state.
- ... etc ...
Edit: lol - in the time it took me to write this there were 5 more posts... Re the "original" VI, I've seen a couple but not looked closely for the last ~60? posts at VIs, only the text.
You are on the right track. Now try cleaning that up so that it fits on one screen. It's nearly impossible to tell what this is doing. Also, why all of the extra controls and indicators? Unless there's a reason for something to be a control or an indicator then don't make it a control or indicator. Finally, I would probably also put the Update rate wait in a separate state. All it's doing is waiting to go to the next state. If the wait is long enough you might also want to use Elapsed Time and cycle through Update rate until Elapsed Time has passed (making sure to have some minimal wait in this state). This will allow you to exit the program during the wait.
John is suggesting that in general, your code will be "better" (by some measure) if any given VI can fit on one screen - that is, you don't need scrollbars to be able to see all of the code.
This limits the amount of "stuff" you can put in one VI, which generally means it is more likely to be "doing one job" - this is sometimes described as/by the Single-responsibility principle.
Basically if your VI does one thing only, it's both easier to write and easier to read.
Then you just create another VI that brings together a bunch of those small VIs to do something more complicated.
So, if I have
- A VI to get the current position
- A VI to set the future position
- A VI to manage states and transition between different states
I can easily work out where to make edits if I want to change some behaviour, and each of those 3 VIs is easier to work with than if I just had one VI doing all of those things.
@labview99 wrote:
Thank you.
Sorry, what do you mean when you say to try to clean that to fit on one screen? I don´t understand what do you mean..
Your block diagram is extraordinarily large. It can actually be made better with Clean up diagram from the Edit menu (if you write good code this actually makes it worse, but it might be a good starting point for you). You've got lots of white space. Put things closer together and make the wires neat. Making the block diagram so large means that many have to scroll to see the whole program, making it extremely difficult to follow the flow. Read up on LabVIEW style for more information.
Edited to add: My post crossed with cbutcher's post. He did give a good explanation. In your case I think that you can fit it well without subvis.
