AnsweredAssumed Answered

VEE Suggeston: ABORT

Question asked by VRFuser on Apr 2, 1997
From:  Tim Axness

I implemented an ABORT TEST using the technique Greg Goebel suggested.  Just
place an OK button with an Exit UserObject on a parallel thread to the test
sequence. The ABORT is executed almost immediately after being activated.  I
found this works well, but you have to structure your vee code well to get
determinate flow. 

> I would also like to see some of the things Juan has suggested here, they
> would be very usefull. For example, when we are executing a series of  
> tests
> we want the operator to have the ability to ABORT the test sequence at
> any given time. We had to implement this just as Greg had suggested using
> a showpanel() with a self resetting toggle which we poll in between each
> test.
> In order to have just one, much less two,  input box operate (I call it  
> asynchronous input for
> want of a better term) as suggested, it would have to be input by another  
> process
> (a process running outside of VEE) and would have to interrupt VEE. This  
> could
> be built into VEE in a future release if enough VEE users really need it.  
> It would
> work something like this:
>  When an input function is called in VEE, VEE spawns another process
>  with it's own window to input the data and provides an interrupt service
>  routine to handle the interrupt from the spawned input process when
>  it completes (via input, cancel, timeout or whatever).
>  The reason for an external process has to do with multi-threading,
>  which Juan pointed out that one instance of a function blocks
>  another until the first is completed. This is inherent in  
> multi-threading.
>  To have two or more at the same time requires two or more instances
>  of the same block of code residing in memory at the same time, which
>  is known as multi-tasking and requires miltiple processes to accomplish.
>  Even using re-entrant code would not solve this because only one
>  entry could execute at any given time.
>  Another option would be to have VEE generate in-line code for these
>  functions which could then be executed separately - the only trick
>  would be to keep track of which one gets the inputs from the keyboard
>  and/or other devices at any given time (when using a separate process,  
> the window manager
>  takes care of that for you).
> These would be nice features and probably not too hard to implement.
> VEE has been on a very impressive upgrade path which has made great
> improvements so far, maybe we can get this in VEE 5.0 ???
> Regards
> Rob Marquardt
> System Test Engineering
> Rockwell Automation / Allen-Bradley
> Milwaukee, Wisconsin, USA
> ********** Juan's comments **********
> However I have several comments to the hidepanel solution.
> The problem, from my point of view, is that there are some objects (with
> input or output information) that stop the application until an input  
> from
> the user is performed. Therefore (an for example), if a message box is  
> used,
> while the message is displayed on the screen, the rest of the application  
> is
> stopped.
> * This panel solution has not the same performances than a Dialog Box
> Integer Input, for example. This object implements a timeout and checks  
> if
> the input is included in some limits. Therefore, if we need these  
> features,
> we should include them in the function of the panel increasing its
> complexity and our work.
> * There are several objects with the mentioned characteristics which  
> allow
> you to perform a interface with the user of the application: all objects
> Dialog Box objects (Text Input, Real Input, Integer Input, List Box,  
> Message
> Box and File Name Selection). Therefore, if we need to have the same of  
> one
> of them, we should develop the corresponding function to perform "the  
> same
> functionality" but being able of not stopping the application. But the
> original VEE objects has been tested and they are developed at a lower
> level, therefore their performances should be better that the equivalent
> user developed functions with hide panels.
> * On the other hand, it should be taken into account that for VEE V3.X,  
> when
> a user function is activated, the application does not work with other
> thread until all the function has been wholly executed. Then we get the  
> same
> problem: until the user writes one input the execution flow of the rest  
> of
> the application is stopped. Although this does not happen in V4.0,  
> because
> in this version a function and other external (to the mentioned function)
> object can be executed at the same time. However we cannot execute the  
> same
> function (with different parameters) at the same time. That means that  
> does not allow to provide two different operator messages at the same  
> time
> (using the same Message Box object or the same equivalent user developed
> function).
> I think of showing on the screen different messages (of different  
> equipment,
> for example) at the same time (each of them has a timeout in order to be
> vanished if the operator is not on line) in a monitoring project is very
> common. But the monitoring of the equipment cannot be stopped until these
> messages has been removed from the screen. This should be compatible with  
> an
> application that does not have a collection with a lot of different and  
> user
> developed functions (which are very expensive to develop and maintain) to
> show operator messages (alarms, warnings, information, executed commands,
> etc.). And more, taken into account that VEE provides some similar  
> objects.
> In order to avoid that, I suggested that all interface object could have  
> a
> switch in such a way that when it is raised the object acts like a wait  
> (of
> the timeout if it is included) until the operator push a OK (for the
> message) or write an input. Meanwhile the rest of the application  
> continues
> executing.

Timothy A. Axness
Applied Physics Laboratory
Johns Hopkins University