Angelo1

Finally I am convinced to let that button completely away. I never thought about the decision making between HW and SW if both is available. Thank you all! -Angelo

;-) You are absolutely right. When I was googleing for a solution I found the same statement. I totally agree. Still I want to keep that button, because I know the users... I am considering calling it immediate stop. A HW switch is needed indeed. Thank you for the good hint. In case of emergency, this is not the thing I want to help me. ;-) I am thinking of resizing my main application a little bit smaller and just have the window with the button next to it... Is there another better solution? -Angelo

Yes, you are right. This is the way that I tried and liked. The problem I am having is, that I need to see and use the stop button any time. The Main application FP is maximized. So the stop button will be hidden behind it. I tried to use the Stop button VI as "frontmost", but then I can not control the main application anymore. Any idea? -Angelo

Hi All, I built a middle complex application, which controls a machine. (Motors, Vibrators, etc.) In case of emergency, I created a software emergency stop to handle motor stop and stopping my application. Now I am wondering what is the best way to integrate my emergency stop button in the main applications front panel? In case the application freezes (yes, I am still debugging some problems due to timing), I don't want the button to not react any more. I tried to do it with a subpanel until I found out, that even if the VI of the button runs, the subpanel won't react any more. Then I tried to to run the Stop-VI separate and bring the Stop Button in front of the main application(like a dialog). However then I can't use the main application... I think you see what is my problem. I can control the stop in a separate VI fine, even in case of malfunction of the main application. But how can I now put both VIs on one screen? Any suggestions or ideas? Thanks, -Angelo

Hi SciWare, Thank you for all the good hints. Finally I tried a different approach. I had three loops in my Master/Slave VI. Every loop I changed into separate SubVI. The previous Master-Loop has in its SubVI version a terminal that indicate a change to the previous iteration/call. (this was the trigger for the notifiers in the Master/Slave design) The Two previous Slave-Loops are are as SubVIs each in a case structure controlled by the indicator of the Master-SubVI. In this way I can fully control the Master-SubVI. And the Slave-SubVIs will be only called when it is necessary. So far it seems that it works alright. Thanks, Angelo

Yes, I had the subpanel before. The Examples made it easy for me to get the subpanel and run the VI. However I did not find a way how to let the VI react to other inputs of my Statemachine (which can change any time). About my Master/Slave VI: The Master notifies the slaves depending on elapsed time. The Timer also has a Pause functionality, which will be activated if the user press the pause button or opens a machine door. So I need to be able to give the Master/Slave VI a run/pause input. This was easy with parallel loops, because they are not running until I stop them but rather are controlled by calling them again the next iteration of my Statemachine. The only way I can think of is to create a LV2 Variable which will be written by the Statemachine and then read by the Master/Slave VI. (wouldn't this be polling again?) And the same procedure for the outputs of the Statemachine, which will determine the next state. Or is there a simple way of running a VI in a subpanel but at the same time treating the input/outputs in the same way as a SubVI? Thanks, Angelo

Hello, I am working on a machine control. I figured out the best way to handle the overall functionality with a Statemachine. The core functions includes two subsystems controlled by time. So I made a SubVI with parallel loops that were polling the state of the indicators whether to run the subsystem or not. As I know, polling loops are not best practice, especially since two loops individually poll the same indicators. Then I changed the parallel loops into a Master/Slave design. That I like very much. Downside, I cannot run the Master/Slave as SubVI, because the Notifiers are killed before they execute, right? What is the best way to do with this situation? Go back to my parallel polling loops? Running the Master/Slave and showing it in a Subpanel won't give me the outputs (indicators) and won't let me start/stop it, right? Thanks for any ideas, or advice! -Angelo, still Newby ;-)

As I understand, it works also in running VI's in LabVIEW 8.6. I tried and figured out that I can use it in Edit Mode (only) even in LabVIEW 8.5. -Angelo

Yes, that was the first thing I tried. I was not very satisfied... ;-) -Angelo

Thanks All, It seems this works only in LabVIEW 8.6. I guess I will stick to my changing colors... -Angelo

Thank you Jens, The black frame I get with key focus is the right direction. However it is not exactly what I was looking for. -Angelo

Hello Lava's, I am still quiet new to LabVIEW. I am working on my final project for graduation. My task is to develop a machine control automation, which allows the user to set up the machine with the wanted parameters and then let the machine automatically run through the whole process. The machine itself is fairly simple and the functions are all programmed. I am slowly getting deeper into LabVIEW. I finished the programming of all functions and am trying to make the user interface more intuitive. When I search for a control, indicator or property node, it will be highlighted on the FP or BD with a black frame which then disappears. I would like to have such an effect for some buttons on my FP. For example when the user makes any changes to the settings, they need to confirm the new settings or discard them. Having an event looking for value changed and then highlighting the confirm, discard buttons in the way LabVIEW does it during editing would be nice. I did not find any property node for that. Is it possible? Thank you very much, Newby, Angelo ;-)