[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 22/11/10 12:30, Philip Whateley wrote:
sketches can be captured and stuck into blobs ( I wish I could find some code I used to have that let me create anotated images on a curses screen using the mouse....Thanks Tom I didn't assume that you were getting at me at all. I think under most circumstances you are absolutely correct. Hopefully I'll be able to get to a meet at some point and we can chat it over, but I'll summarise the workflow I am involved in. Basically, when a shop floor operator thinks he has a problem, he will initiate a problem solving exercise by gathering some data on a paper chart, calculating from the data the way the process should be operating, and then using excursions from the normal operation as triggers to initiate problem solving exercises. If he doesn't find any excursions he would normally drop the charting or reduce the frequency of sampling and move on to charting something else. This whole exercise could take as little as one day before he/she moves on to something else. All of the above steps will be individual to the specific problem although based on general principles. There is no way to determine in advance the type or structure of data required, or where it is to be collected. The only electronic method of doing this would be for the operator to use a spreadsheet but that would be too limited in many cases as it is difficult to add freehand sketches etc (bearing in mind that this is an operator led process)
I know that there are companies who collect all the data that they can imagine might be useful, but they will still miss 90% of the information that's important. The other problem with the centralised data collection approach is that it takes the information and the problem solving away from the shop floor - the result of which is that problems are only identified when it is too late to trace the root cause. The use of R, gGobbi, Mondrian etc really comes in when the operators get stuck, and I would then use some of the data (possibly 20 to 100 data points) they have collected to look for clues as to what is going on. My main tool for that would be Exploratory Data Analysis using Interactive Graphics (Mondrian for categorical data and gGobbi for numeric
not sure about gobbi but the other two can read in data from mysql.
I don't in principle have an attachment to any particular file format, but gGobbi and Mondrian use character delimited, so I would need to export as CSV or tab delimited anyway. At the moment I do that from OOo, but it could be from SQLite I guess - the main thing is that the design and implementation should be as quick as typing directly into a spreadsheet. Also there is no structure in the data which would require it to be anything but flat file.
you can make the flat file equivalent in a db: rowID, columnID,256char data often worksthen once the data is in the db its really easy to analyse and transform so you can collect the data for...
see above - its a catch 22 often - you cant tell what the data is until you collect it and it wont fit into what you though it would. I used to get so pissed off with two months planning getting screwed up by real data using 'proper project planning methods' so I use 'agile' methods A simple table like the one above combined with a simple web form can collect almost any ascii data with about 2 seconds of customisation in the same web page*, which once captured in the db can be polished up later...I guess there is a big difference between a generic situation where you know in advance what data you want to collect and will be collecting it for a long time, and a specific situation where you won't know what you want to collect in advance, or where you want to collect it, and will probably only need it for a day or so.
Point taken - just a bit of a bugger when the maintenance guy leaves the bit of paper down there and you have to start again....To apply electronic data collection to the specific problem solving situation you would need to perform systems analysis, design build and test a database, design build and test code to enter and pre-process the data, install networking and hardware, all of it different for each problem, with a time-scale of say 10 minutes from identification that there is a problem to be solved - and usually at 3 a.m. All of this so the operator can take the data from the screen and chart it on paper manually so he can make notes on the chart for the maintenance guy to take with him when he crawls into a confined space wearing breathing apparatus to look at a hydraulic valve which might be the problem. (I exaggerate but you get the idea!)
Tom * if you think that could be of use I can send you a php example . -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq