Why do controls lock up after initializing RS-232

[SciManStev]

As much as I wish I could start again, I do not have that luxery. You did point me to that even structure that is locking the panel. I did some experiments and confirmed that is the cause of the problems. The question now becomes how do I release that even structure, once it is no loger needed? That section of the code is used to level a rotary head to within 0.001°. The plate the sensor is attached to must be level within that tolerance. That is why that section is only used until a level is obtained. Then the program will run the huge sequence structure one time for each new unit tested. If I can clear the Event structure after it is finished, or set it so that it doesn't lock the front panel in the first place, all my problems would be solved.

[dkfire]

You are aware of that LabVIEW is a dataflow language, NOT a text based language. 

The wires in LabVIEW is you variables!

The frame 4, False, 23 is just misuse of the sequence structure. LabVIEW is able to do may things in parallel.

[SciManStev]

I agree. That section, 4 False, 23 has stemmed from my past experience blanking or making visible hundreds of variables. Until today, all of the target computers I work with had only one core, without hyperthreading. When I first started writing programs for them, any parallel structure would simply not work, so out of necessity I learned to make everything sequential. Clearly the time for that is past, but I am on a deadine to finish this project today, or tomorrow morning at the latest.

As for Qbais having a state transition machine, I really don't know. I have never had any formal training in any language, other than what I have learned on these forums. I was just assigned a task to do, with a very short deadline, and told to do it. I appoligize for my rough style of programming. I have been commanded to learn C as well, but in the last 3 1/2 years, I have been given exactly 1/2 a day to do it.

[Ben]

---

@SciManStev wrote:

As much as I wish I could start again, I do not have that luxery. You did point me to that even structure that is locking the panel. I did some experiments and confirmed that is the cause of the problems. The question now becomes how do I release that even structure, once it is no loger needed? That section of the code is used to level a rotary head to within 0.001°. The plate the sensor is attached to must be level within that tolerance. That is why that section is only used until a level is obtained. Then the program will run the huge sequence structure one time for each new unit tested. If I can clear the Event structure after it is finished, or set it so that it doesn't lock the front panel in the first place, all my problems would be solved.

---

Somehow I feel like I am giving you rope to hang yourself   but since you think that is all you will need (and you promise to never hire me to fix it ) then...

Search this site for...

"Ton Nugget Dynamic Event"

You should find Ton's Nugget where he taught us how to use dynamic events. Dynaimc events let you register and un-register events and in your case "shut-off" the event.

My gallery here has some screen shots of what it looks like when you use dynamic events.

Have at it!

Ben

[dkfire]

Just to make one thing clear. There are NO variable there! There are controls or indicators!

And what you are having are property nodes for controls.

No matter if the processor has one or two core, is it the operating system that make it "parallel".
You don't have to force a sequential execution in LabVIEW if there are NO need for it, LabVIEW will take care of it for you. 

[Mark_Yedinak]

As much as you would like to defend this code it is indefensible from an LabVIEW perspective. The only way this may work for you is if you some how happen to fix whatever bugs exist today and you NEVER have to touch the code again. EVER! This application is a house of cards and I'm not convinced it would look much better in a traditional text based language either. Common architectures exist for a reason. They have been proven over time to work. A state machine would be a much better implementation and would be easier to understand, maintain and get working. There is very little hope of trying to maintain proper state information in this application. Once you enter a sequence frame you MUST execute every frame. As mentioned the main sequence frame has 207 frames. Virtually every frame also has a sequence structure. How do you ever expect to keep things straight when each frame will basically need to know what happened in every frame before it.

As suggested, write down on paper what you need to accomplish, what your basic logic is and where your decision points are. From there define a state transition table. From that implement a state machine.

Though I am not a contractor I agree with Ben. You would either have to pay me a ton of money to completely rewrite this code or I wouldn't touch it at all.

[SciManStev]

I am truly thankful for the information and criticism. I really want to learn correctly, and am not afraid to admit I have done wrong. I will try Bens suggestion above, and I will work to better utilize LabVIEW. I still do not know how to perform these tests in any way but one step after the other, as they require an operator to enter one piece of data, rotate the rotary head, enter another piece of data, etc. but I will make an effort to learn. One completed data is calculated and results reported in a Word document, as well as being saved to a database. I have created entire systems based on similar techniques complete with automation, databases, and detailed specific report generation. Most of my programs are gigantic, with this one being smaller than normal, as less is called for in the test of this particular sensor. The people who use my programs are delighted with the functionality and ease of use. Anyway, I really wish to thank every one of you for your excellent comments. Now I will start digging into Ben's solution.

Thank you!