string state machine not working

[metzler]

I have a producer/consumer architecture, and am having problems with the state machine recognizing the new state. 

According to the probe, when the event structure triggers, the input into the case selector is:

 "HV OFF

"

(with the carriage return), but the case is called "HV OFF". 

My strings are combined into an array with the build array function. 

One of the states is working correctly, and the probe shows the state into the case selector is "serial number" with the ending quote on the same line.

Has anyone encountered this?

[Dennis_Knutson]

Obviously your input string does not match the case. You might as well be passing any random string. Get rid of the carriage return.

[RavensFan]

It is also shows a good reason not to use a string based state machine but to use one that is based on type def'd enums.

[metzler]

I don't know how to get rid of the carriage return. 

I have included a small sample of the problem - this vi has other problems (like not exiting correctly) that I am not concerned about.

When you run the vi and press Enqueue Element, please notice the Case is default case, but the case selector shows the case that should be next.  If you place a probe on the case selector, there is a carriage return after the string, which I believe is causing the case to go to default.

Does anyone know how I can remove the carriage return?

[metzler]

How do I change to a state machine based on type def'd enums, and would that allow the state machine to automatically index?

[metzler]

I have figured it out - in the sub vi, the strings have a dash at the end - that must mean carriage return.  If I delete it, the carriage return deletes and everything operates good.

Thanks for your time. 

Ravens fan:

I still would like ot use type def'd enums if they can be indexed.  Can you tell me how I do this?

Thanks.

[RavensFan · Accepted solution]

Go to each string constant, right click and have it display slash codes "\ codes".  Now you see extra character which is actually a line feed character, not a carriage return, and can delete it.  (You can delete it in normal display as well, it is there, you it is just trickier finding it since it doesn't really appear.

To do it as a typedef'd enum, create an Enum control.  Edit the items and type in all the states that you want.  Right click the control and customize.  Pick Type Def as the control type in the toolbar.  Save the control as a .ctl file and allow it to go back to regular LabVIEW window.  Now you just use a copy of the control, or a constant created from the control.  You can't accidentally type anything wrong because you have an enumerated list you can select from.  If you need to add another case, edit the .ctl file and add another item to the enum control.  Now all instances of that control and/or constant that refer to the typedef file are automatically updated.

Your currently implementation of a string based statemachine is kind of mixed up.  You are working with a queue, but each element of the queue is also an array.  So you are dequeueing an array, stepping through that, then when you are done, it would grab the next 1-D array element.  Except in your implementation, you have nothing that stops the inner while loop because you never have a True wired up to the stop terminal.

With the enums, what you do is enqueue each each enum.  If you wrap the enqueue element with a for loop, and feed it an array of enums, then it will enqueue each step in order.  The producer loop will dequeue each step in order, and you don't need that inner while loop that you are currently using to autoindex your array of strings.

[metzler]

Thanks for the detailed information about how to show the slash codes, and how to change to a type def'd enum.  I know this little example vi does not have the stop wired - this was just a quick example of my code.