LabVIEW
Is It smarter to dynamcially call Sub VIs or Reformat Code so that 1 Shift Register Controls SSM
@vanceblake wrote:
Is it possible to retain the default state I currently have and have buttons that allows me to change from the default state to a waiting for calibration state, and then just transition from waiting to calibration and then from calibration finally back to the default state? With the last two transitions happening automatically?
Anything is possible. You just have to program the logic for your state transition. You could also do it like you're doing now while retaining the current default by having a 2nd shift register that is "Next State" which is called when the appropriate criteria are met. "Next State" would be changed when you transition from the default to a calibration state.
You still seem to be trying to complicate things. This can be done in a simple way as discussed in this thread (by the way, when you're still working on the same problem it's best to keep everything in the same thread). Are you wanting this to now not be fully automated? A simple state machine will work for your application. While I would have more states than I suggested in that thread (I don't like to put while loops inside while loops as it makes my program non-responsive) it would at least get you up and running. Have you tried the 6 states that I suggested here?
@vanceblake wrote:
The reason I cannot use the six states you mentioned is that the sensors do not exist either waiting for calibration or calibration states. So I need a default state that is just taking samples and temperature right now. In the future that default state will also be accessing other sensor data not related to calibratio, but for now what I have is enough.
You're already using those 6 states. I think, though, that you are trying to build a producer/consumer in one loop. Study up on a producer/consumer and see if that isn't a better architecture for what you're trying to do. This architecture will allow you to have a loop that is constantly acquiring data and sending it to the other loop for processing. The consumer loop can then be a state machine if desired.
@vanceblake wrote:
Hi johntrich1971,
And apologize for overcomplicating things, but I am trying to deliver a level of functionality and control that can be tailored for future projects and uses. I see an idea that works and I want to implement it, however I recognize that I am not picking the most efficient method.
By overcomplicating things you are actually making it less useful for future projects in my experience.
@vanceblake wrote:
I guess my real question is why do named boolean buttons not control the smaller SSM like a standard enum control would?
I don't understand what you're talking about here. Booleans and enums are two entirely different data types. You can use an array of booleans and convert it to the number to make the selections in your case structure like you're doing in your code, but wouldn't it be better to just have an output for each button in your event structure in this case?
Also, in looking at your last bit of code it gets stuck in your default case only making one acquisition until you press a button. Put a timeout in your event case and let the output be your default case. The event structure won't continue until an event has occurred.
