Multiple Triggers to Select States In Simple State Machine

[vanceblake]

Hi, I wanted ask if the way I wired the shift registers to select my states is correct? I don't want to test my code on the sensors I am using because improper commands can damage them, and I have a limited quantity available for testing with the shortages in the supply chain.

I am using visa serial commucnication, and I have 4 states. The default state samples gas ppm, the other 3 are connected to calibration states. I tried wiring all the left side shift registers to the case selector but that did not work. 

My current VI is below, and i apologize for the slight clutter. Any corrections or upgrades are greatly appreciated.  

[GerdW]

Hi Vance,

---

@vanceblake wrote:

i apologize for the slight clutter.

---

I would start with cleaning up that code:

Do you see the Rube-Goldbergs in this tiny part of your block diagram???

• No need to check the same value for "==64" and "<>64" when there is a NOT available…
• No need to add this BooleanCrossing function…
• When you know the number of loop iterations before starting the loop then you should use a FOR loop…

Switching to the next state shows this:

It doesn't get better…

• Why calculate the very same result three times?
• Why compare a boolean with FALSE? Ever heard of NOT before?

---

@vanceblake wrote:

I wanted ask if the way I wired the shift registers to select my states is correct?

I am using visa serial commucnication, and I have 4 states. … I tried wiring all the left side shift registers to the case selector but that did not work. 

---

When you want to combine several conditions to select the next state then usually you define something like "condition1 AND condition2 OR condition3". I don't see any of those AND and OR in your code…

[JScherer]

Step 1: is definitely to clean your code.

• Make a Project
• Convert those complicated strings to a ring typedef control 
• Create Sub VI's
• Use the Sub VI's you make to remove repeated code (this will answer you question)

Step 2: Make Unit tests Make VIs that:

• Emulates your sensor inputs and outputs
• Tests your commands to a single sensor
• Emulates your larger program

The trick is never to try to fix your big program (We will always fail). Instead make your big program out of smaller programs you know work. 

[vanceblake]

Hi GerdW,

Thanks for your help. Regarding your first comment, I like Rube-Goldberg machines cause I am fan of OK Go, but I get your point. I switched from the original way that I was stopping the while loop. The command inside the loop is a status check of a bit vector stored on the sensor. When the calibration is active that bit vector was supposed to be a nonzero number, but initially it is zero which is why I used a boolean crossing. However I cannot get the bit vector response consistently, and then the unflatten from string function corrupts and stops the program. But you're right, I should have simplified everything and used a for loop once I switched to the current setup.

Regarding your second comment, that was just copy paste galaxy brain moment. I should have just connected the wire from the original source. Thanks for pointing it out to me. Also, I was using the booleans as flags to prevent reentry into the loop once the calibration was finished. I saw that method on a previous forum example and thought it would be useful for me as well.

Finally, I was trying to avoid a complicated string of ands/ors/nots for selecting the cases. I figured building a gate for each would be easier.

But, my question was whether or not the shift registers attached to each calibration TF case structure would successfully pass the correct state to the case selector in the current setup? And If not, do I need the chain of and/or/not operators to have the proper structure all connected to the shift register that is paired with the case selector?

Best Regards,

Vance

[vanceblake]

Hi JScherer,

Thanks for your advice. I am complete novice when it comes to the full capablities of LabVIEW, and have built this current SSM VI through scouring the forum and respected user recommendations like yours and GerdW's. 

With that being said, I have no experience with calling a sub VI from a VI, but I do recognize that my code is getting messier as I try to consolidate the 4 states into 1 SSM. Originally each file was its own self contained code. But, I will look into this approach to improve the coherence and effectiveness of my program. 

You mentioned a ring typedef control, but when I searched for ring typedef control I didn't see it in the help menu. Is it just the ring constant?

Finally, I agree that the final form of this code will be a system with loadable or program-called modules that each serve a different function. But, right now this is an ongoing research project, and I have to prioritise progress over perfection. Nevertheless, near perfection remains the goal.

Best,

Vance

[JScherer]

Vance,

I work in research as well, trust me that going slow to build your foundation will pay off long term when your program works on the 1st 2nd try. 

Always try to build technical wealth over debit. 🙂
https://delacor.com/first-thoughts-about-technical-wealth/

How to make a subVI:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YK4VCAW&l=en-US

How to make a project:

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/creating_lv_projects/

[vanceblake]

Hi JScherer,

Trust me, I would love to go slowe, but I have weekly meeting with the outside company thats funding the work, so I gotta show that I am getting the job done in stages. Thanks for the links and all your help!