Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Callahan

  • Birthday 05/11/1983

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
  • Interests
    LabVIEW environnement<br />LabVIEW community<br />bug seaking<br />nice and simple code
  1. OK, You're right. The problem subsists only for top-level VIs. And it's possible to have more than one top level VI. Hum...ok, the problem is not so big as I thought, but it exists, are you agree ? This reference come from the constant "This VI". It is not an explicitly open reference. It's like the constant reference created from a control. It is not able to maintain VI in memory. So, it's not necessary to close it with CloseRef VI. So, you're right too, I removed the CloseRef from the CleanUp state, and my Close Panel method run.
  2. "You are specifically trying to address the use-case of this VI being top-level." Yes and no. If this VI is used as a sub dialog box (front panel displayed), it will stop immediatly after FP:Close method and all states after UI: Front Panel State will not execute. "The main problem is the "UI: Front Panel State >> Close" state which executes before the Data Cleanup." YOU ARE TOTALY RIGHT!!!! "If closing the front panel means that no other VI panels will be open then" Not necessarily. "yes, this will cause LabVIEW to leave memory and terminate all VIs." Closing a front panel previously open without reference open to it will stop execution of the code. "However, since LabVIEW will exit at that point, then it's not of too much concern if we cleanup the VI reference. Is there?" This is not what I mean. My english is not really good, but I'd like you understand what I think. For me, whatever use of the state machine (MainVI, subVI, dymanic VI, with FP displayed or not, etc....), the FP: Close method can't be where it is actually. It's a nonsense to have an Exit state and not pass in. I'm really sure 80% users of JKI state machine use it as it is, and don't know there code in CleanUp is not executed and the Exit state not used in 60% of the cases. "However there is a problem if you are performing other code in that frame such as file IO or hardware communication tasks." You're right. But CleanUp is CleanUp. If I was a TestStand user and want using the JKI State Machine, I would put code like Close VISA and things like that in the CleanUp State. "To address the issue of not executing the Data Cleanup state after the VI panel closes on a top-level VI then you will have to modify the sequence. You can add a state before the data cleanup and panel close state to perform any additional tasks you need. One way is to edit the Macro:Exit as shown below." It is exactly what I have done. I modified the sequence, not by adding state, but by moving the UI: Front Panel State >> Close : Data: Cleanup then UI: Front Panel State >> Close the Exit but even if this is the Exit state which get the true stop condition, this is the UI: Front Panel State >> Close which end my VI. "Regarding the Exit LabVIEW function. This is not required because once all front panels are closed then LabVIEW will exit." ok "Also note that you should not add any code in the Exit state (as stated by the comment on the diagram). That state is only there to stop the loop." YES, I see. but the loop is removed from memory before it really stop with the true condition. "Please keep in mind that we fully expect that this framework will not address 100% of the use-cases, and that it's expected that you will have to modify the sequences as you require in your application." Yes, I understand. But I think the framework have to match closely to the widespread using of a state machine, I mean a Front Panel displayed, a non-dynamic VI, and a code which end at the Exit state. "Having said that, I can see how it may be misleading to call one state, Data: Cleanup, and people may end up putting critical code in there that may not execute all the time. perhaps we should rename that state to: Close Panel Reference, and create a different new state for the cleanup code. We will consider this idea in a future release." For me the problem is elsewhere. If I decide to close some references of a complexe application in the CleanUp state, I possibly have a memory leak, because the CleanUp state will not be executed. Thanks for your time, and sorry for my insistence. I'm nively proud to discuss whit M. Kring and M. Aivaliotis ^^ Callahan
  3. Hello Michael, I think it is not the good solution : The State Machine VI will open a reference to itself, yes, and be able to maintain itself in memory. But if this VI is used as a subVI or as a main VI, so the CleanUp state will close this reference with CloseRef VI. It involves that the last state Exit (the one with the stop while loop condition to true) will not execute. Your solution works, but for me if the state Exit is implemented, the code have to pass in it, exit the while loop and finish properly all the code in the diagram. It is just a philosophy question...It avoids to cogitate a lot to understand how the state machine will stop. In all cases, my point of view is that it is necessary to update the JKI state Machine. I do love OpenG and JKI work, but for me this is a problem which can absolutly be resolved for everybody. Other point : you did not wire the error output of the OpenRef VI... ^^ Thanks for your time ! Callahan
  4. Hello Jim, Any news about that problem ?? Callahan
  5. Thank you very much for your answer Jim. I have some others things to add : There are 3 mains ways to use a state machine : -as a Main VI -as a subVI -as a dynamic VI For me, the CleanUp state will execute correctly only if state machine is used as a dynamic VI, because there will be a reference open to it. I think the JKI state machine can't be used as it is, while I'm pretty sure that common users use it as it is and want use it as it is. I think many people think their cleanup state work correctly, because they have never errors, but in fact the code is simply not executed. Are you agree ?
  6. Hi all, I think I have found a bug in the JKI State Machine. Let me explain it in details : 1) "Macro: Exit" If "Close Panel on Exit" is TRUE, ie : -executable mode -or Front Panel originaly closed (called by a splash screen for example) Macro: Exit so, the states put in "FIFO" by "Macro: Exit" state are : UI:Front Panel State >> Close then Data:Cleanup then Exit 2) "UI:Front Panel State >> Close" The first executed state "UI:Front Panel State >> Close" execute the "FP : Close" method, if the Front Panel is "Open". HERE IS THE POINT The "FP : Close" method put the VI out of memory if there is not at least one reference open to it. So, code in "Data: Cleanup" state DOES NOT EXECUTE (no code has to be put in the "Exit" state). 3) Application 1 -Put a new blank JKI state machine on a diagram -Shunt the "Close Panel on Exit" to TRUE -Put break points in "Exit" state and "Data: Cleanup" state -Run the VI ---> You see that the code stops before breakpoints, or just at the first break point put in "Data: Cleanup Up". This is due to the fact the "FP : Close" method take a certain amount of time to totally execute. IT IS A RACE CONDITION. If code in "Data: Cleanup" take a lot of tim, it would not be completly executed. 4) Application 2 -Put 3 sequenced dialog boxes in the "Data: Cleanup" state. Compile the code. Execute it and quit it. The 3 dialog boxes are not displayed. 5) Note 1 NI says : "In order for any VI to run, it must have at least one reference open to it. When you display the front panel of a VI, the front panel itself serves as an open reference to the VI". ---> In the case of the JKI state machine, the VI server reference constant "This VI" is used. For me, the reference "This VI" does not open explicitly a reference on a VI, so it's not necessary to close it as it is done in the state machine. If "This VI" was an explicitly open reference on the VI, the "Close Panel on Exit" method would not stop the execution of the VI but just hide the FP. 6) Note 2 The "exit labview" function is not used in the JKI State Machine. If the VI concerned is the main VI, the "exit labview" has to be used, I think, no? Conclusion, to discuss -The close reference function used in the Data:Cleanup has not be used. I'm interesting to know your point of view about the "This VI" reference. For me it is not an explicitly open reference able to maintain the vi in memory. -The "FP: Close" and "FP: Open" methods can be used without wiring the reference inputs -The order of the states in "Macro: Exit" has to be changed : Data:Cleanup Exit UI:Front Panel State >> Close -Maybe the "FP : Close" method has to be put out of the main while loop of the state machine, to properly stop this loop. -In a main VI, the "exit labview" function has to be used if there is more than one main VI to ensure the total close of all VI. But in this case, if "exit labview" is used, "FP : Close" method can't be used before. Please, let me know your point of view. All this topic is done after some tests, but errare humanum est. Callahan
  7. Hum...just a question : Why the "Destroy User Event" function is not used in the upside example ?
  8. I got exactly the same problem. The solution works, but ... it solves the consequence, not the cause. PS : Thanks for the huge smart wonderfull exciting work with OpenG and the JKI Tools. You guys are worldly known super stars ^^ I was a LabVIEW developper in the near past, but even it's not my actual job, I continue to pratice and use it, because I do love LabVIEW ! The french LabVIEW community loves you.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.