[AccessD] I just don't believe this. )&*()&)(&)&!&*^@(*&!!

Bruce Bruen bbruen at unwired.com.au
Tue Apr 24 18:31:35 CDT 2007


Hi Susan,

Yep, they are truly that custom.  Basically the app is a status monitor for 
injection moulding plant, sort of like a fire panel, with a twist.  There are 
essentially 10 "object types" each having a set of conditions and statuses. 
The objects fall into 2 heirarchies (structural and operational) of 6 and 4 
levels respectively. The final installation will have about 500-600 real 
objects that are manually monitored several times a day.  Everything's normal 
status is "warm" but there are a lot of conditions that are "warmer" 
or "cooler" than norm which may need attention. That attention depends on the 
operator getting a clear overview of the entire environment for the object, 
its job mix, the particular job type etc etc.  If an object gets too hot or 
develops some fault, the realtime monitoring equipment sounds the alarm and 
stops the machine. This app essentially gets the log info from the realtime 
stuff and is aimed at detecting problems before they happen, by looking at 
the variance of the signals over time and presenting the user with an overall 
view at each of the levels that they can drill down through to "inspect" a 
particular machine (in fact, down to specific components of machines).

So, on line "A" we might have a feeder, an injector and a conveyor.  For 
certain jobs, using certain dies and certain plastic mixes, the injector may 
need to run slightly hotter than for other jobs and if it doesn't then it 
will gum up.  There are lots of conditions and lots of states, and of course 
there are always new job types that raise new conditions and states.  Rather 
than reprogram the realtime monitor (and this app) over and over, they set 
the realtime fault levels at a "significant" fault and hope to use this app 
to detect any "errant but within bounds" event.  

There are 4 "main" forms - 3 of which are continuous forms with around 
10 "signals" per row and a treeview+inspector form/subform - that make up the 
major view of the system.  The continuous forms show all 500 objects - so its 
important that the operator can recognize an aberrent signal level by quickly 
scrolling through the list. Hence the need for all the custom formats! The 
treeview form, which has 6 subforms that swap depending on the "type" of node 
selected in the tree allow the user to modify the monitor levels on the fly, 
say to loosen or tighten the variances allowed on a new die as it beds in etc 
etc.

Sorry about the long winded story, but its quite an interesting app!

regards
Bruce

 
On Wednesday 25 April 2007 01:30, Susan Harkins wrote:
> Bruce, is each field truly that custom? You do know that you can change
> default formats for a form don't you? Of course, that doesn't help with the
> problem at hand -- sorry about that. :(
>
> Susan H.
>
> After 6 weeks work of setting conditional formats over 32 tables, 65 forms
> and
> 12 reports I accidentally hit ctl-leftshift-alt-prtscn-scratchnose which
> produced a "YOUAREGOINGINTOHIGHRESOLUTIONMODE" popup, with apparently NO
> WAY TO CANCEL IT!



More information about the AccessD mailing list