Dan Waters
dwaters at usinternet.com
Wed Apr 25 08:01:27 CDT 2007
Nice! If you can get into the sounds, smells, and looks you'll have manufacturers knocking down your door! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, April 25, 2007 5:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] I just don't believe this. )&*()&)(&)&!&*^@(*&!! Ah now that's a real tricky piece of work. :-) Basically the realtime monitors log every measurement they make (~26-46 per minute) to a text file with the first 20 bytes being a DTS. All I'm doing is everytime this app gets invoked is to read the log file, ignore anything that is less than the "last stamp I know of" and process the rest. Tricky eh! and now I've told you, I'm afraid I'll have to .... Sometimes simple is best. Dont forget, these people open the app 1 or 2 times per shift, check things out and close it. It's not doing or pretending to be am "active" monitor, just something to make the operator's life a bit easier than walking around a 2 acre floor, taking and logging readings, correlating them to the current job mix, checking the mix against the schedule.........etc etc. Actually, these guys spend most of their shift walking the floor. Apart from die jams, which happen every couple of hours or so, most of the time they ... wait for it essentially use their faces to detect if anything is slightly aberrent. That is, these people can "just tell" by walking past a machine line whether it sounds, smells, looks and feels like its going full bore and OK. Currently, we are working on "feels", i.e the operating temps amd feed rates. If I can get into the "sounds, smells and looks" regime. I'll be applying for patents and making an aggressive takeover for M$ ... :-) On Wednesday 25 April 2007 11:22, Dan Waters wrote: > That's Very interesting! > > How do you get the real time info from the machines and components? > > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen > Sent: Tuesday, April 24, 2007 6:32 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] I just don't believe this. )&*()&)(&)&!&*^@(*&!! > > 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! > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com