10-03-2011 11:01 AM
I am initializing an RS-232 port to control a rotary head. It works fine in it's own loop, but when I exit the loop and move on to the rest of the program, all controls are locked, and I can only use the Stop button. This happens even if I close the port after each use. If I use it once, then it locks everything past it.
Thank you!
10-03-2011 11:10 AM
You'll have to post some code so we can see how you are doing what you are doing.
10-03-2011 11:34 AM
OK. Here is the program. It is still a work in process, but without the RS-232 port it work perfectly. I built it by putting all the Serial communication parts in a case structure, set to false.
10-03-2011 11:53 AM
Just out of curiosity, if you change your event structure such that it doesn't lock the front panel while processing, does that change anything? I can't really test your program, but clearly a problem with the logic in the event structure could be at fault.
10-03-2011 12:01 PM
When I put all the serial parts in case structures, the program works perfectly. As long as I stay in the first communication while loop, the program works perfectly. When I hit the Finished button to move on to the next item, I set key focus to a control where I want to enter a name. The cursor flashes in the control, but I can't write anything. I can't push the End Program button. The only thing I can do is push the Stop button on the tool bar. I am trying to add the VISA clear function after each step, to see if that works. I don not have that particular rotary head on my development system, but as it is just writing VISA commands, I had thought it wouldn't matter, but it locks up my system, and the target system with an executable on it.
When running as a separate program, the rotary control work perfectly, and has for several years. Clearly something is causing it to lock, and I'm hopeful it just needs the Clear Visa function. I will be ready to try that shortly.
10-03-2011 12:03 PM
majoris: Maybe it's just me, but where do you see that event structure ?
And I can only say one thing, redesign the code!
Take a good look at the statemashine and producer/consumer design pattern.
With a stacked sequence structure with 206 frames holding while loops and other stacked sequence structures it is impossible to have any idear of what your code is doing. And there are way too much code that is just copy/paste.
And all the local variables is also a night mare.
10-03-2011 12:15 PM
It has been removed. I used many of them when constructing the program, so I could pass each section without a hangup. I used a case structure around each serial communication and set it to a constant false, so it would never execute. That first while loop in the program was inside a case structure, set to false, as well as the port initialization, and every other serial command through out the program. WIth all the communication walled off in a False Case Structure, every single thing worked perfectly. As soon as I removed the case structures, I had issues. I am including the program with the first 3 case structures as I had them when I made the program. They are in frames 1, 2, and 3 before you get to the large while loop.
10-03-2011 12:19 PM
Take that code, throw it away and start over from scratch. That is probably one of the worst VI's I've seen for abuse of Stacked sequence structures. One that appears as soon as the VI opens has 206 frames. And there are are multiple levels of stacked sequence structures as well.
I did a little searching and found an event structure in 2 1 0 (That is the only way I can describe how someone can find it if they look through sequenc frames from the outer most working in.) There is an event structure with a case for Key Down? It is set to lock front panel until complete. It is extremely likely the user is going to hit a key sometime during the execution of the program. And considering the nearly exponential number of sequence frames you have, it is extremely likely that the event structure will not be in the path of execution and may never get there again becuase the front panel will be locked, and other parts of code will be stuck in loops that won't end because it will require user interaction to end them.
There are two common architectures that handle the vast majority of LabVIEW programs either separately or in combination. State Machine to control order of execution of various steps of a process. And producer/consumer where one parallel loop is running and will send data and/or commands to another parallel loop for further processing.
Read up on those. Then throw away this VI and don't look back. Define what you want your program to do on paper before you lay down any wires. Use flow charts and/or state diagrams to show the interaction of pieces of your architecture.
10-03-2011 12:25 PM
The code is designend to run a sequential test of a specific Inertial Sensor. The variables are mandated by the customer, as is the entire test. 15 years ago I had written this in Qbasic, but as we are getting new Windows 7 64 machines, I needed to rewrite the test in LabVIEW. The sequence structure just carries out the customer specified data entry of variables. Each of the entered variables is stored in a database, so the written report can be regenerated at any time. I could have used the A(0) through A(40) variables in an array, but it was just easier when it came to the report generation section to match what I had done 15 years ago. During the test, is is required to rotate a precision rotary head, and enter the putput from the sensor. There are multiple parameters that the customer required us to check.
10-03-2011 12:34 PM
Forgive me if I am wrong but din't the QBasic code have some type of design maybe a State Transition Diagram could describe?
A State Diagram is just LV's version of a State Transition Diagram so converting over to a STD is much easier to develop and maintain.
Ben