I thought this would be nice for the first thread here. Any PCDMIS part program I have that saves stats I put this at the begining of. It looks for and deletes the xstats11.tmp file when executed. This avoids the way of doing it manually which is usually right after things screw up.
Just started to mess with this. Very timely, Craiger. My management wants me to hook my machines into SPC this month. We have InfinityQS and it seems to work off the Xstats11.tmp file.
I knew your were psychic (or psycho whichever applies), but this beats it! Thanks.
I know this is not related to Datapage, but someone may look at this to troubleshoot other SPC programs so....
If you are using a program like QCCalc(and maybe other SPC programs), you may not want to delete the file everytime. For example, if QCCalc is not running at the moment of the inspection, it will process the xstats11 file when it does get started. While QCCalc is off, the xstats11 file will accumulate part data and then is processed when QCCalc starts later. It acts as a temporary storage of part SPC data.
This would apply to any program (other than datapage??) that uses the xstats11 file.
I have not used Datapage, why is it necessary to delete the xstats11 file? Could you just make a single PCDMIS program that would delete the file instead of adding to all?
Data goes to the xstats11.tmp file. From there I am assuming a utility of some kind sends it to Datapage's database. I am only assuming it is some type of utility as Datapage does not have to be running for this to take place. Perhaps that is where QC-Calc differs. It sounds to me like QC-Calc imports this data. With Datapage, after the info is transferred to the Datapage database the xstats11.tmp file is either emptied or deleted. It is when there is some kind of failure to upload the data to Datapage's database that problems occur. Partial and appended data in the xstats11.tmp file exasperates this problem and the transfer of data will not take place. The file needs to be emptied or deleted. Unfortunately I do not know the ins and outs of Datapage enough to know exactly what is going on that causes this. Like many others all I know is deleting the xstats11.tmp file fixes it. If an xstats11.tmp file exists when PCDMIS is done measuring a part it appends the data to that file, if it is trashed then you get an error trying to update the database. If there is no xstats11.tmp file PCDMIS creates a fresh one. The file that gets deleted is useless, it either contains junk or nothing at all so with Datapage there is no consequence to deleting it. It can't hurt so it only serves to help, QC-Calc I can not speak for. I recommend this only to users of Datapage. Actually I recommend to users of Datapage to not use Datapage but let's face it there are a lot of people using it. As a product, it will be gone soon that is my prediction anyway. I have little faith in the future of Datapage but there are many seats of it out there and will continue to be in service for a long time so if you must use it this code in each program (at the beginning mind you) will save some headaches.
If you put that code in a standalone program then that program will have to be executed once every time before you execute your program for measuring a part. Either that or you will have to put it into a sub in a standalone program then in every part program call that sub. It is probably best to just put it in every program.
OK, that helps me understand how DP processes the data and the problems and I can understand why you would need to delete the as a matter of course when using datapage.
Then my advice earlier only applies to non-datapage data consumers. Jan_d said that he was going to use this with his Infinity and he may want to reconconsider untill he determines exactly how Infinity handles the data.
So, I guess bottom line, if your SPC program(including Datapage) uses xstats11 file in a non-accumulating way then using the delete method is a useful workaround.
OK, that helps me understand how DP processes the data and the problems and I can understand why you would need to delete the as a matter of course when using datapage.
Then my advice earlier only applies to non-datapage data consumers. Jan_d said that he was going to use this with his Infinity and he may want to reconconsider untill he determines exactly how Infinity handles the data.
So, I guess bottom line, if your SPC program(including Datapage) uses xstats11 file in a non-accumulating way then using the delete method is a useful workaround.
Well, you can also use it as an accumulating way with Datapage. If you are running a 30-pc study, you can tell it NO when it asks if you want to update Datapage and the data will accumulate in the XSTATS11.TMP file until you DO tell it to update. You can wait until all 30 parts are checked, then update at the end. Myself, I would NEVER do this because you never know what kind of error will pop up and when and what will it do to the data. Also, if the beginning of the prgoram deletes that file, you will never get any data except the last part checked if you wait until you are done to update. HEY BOOGER-BOY, do you use an UPDATE command at the end of your programs to send 'force' the Datapage update so you don't lose your data?
Yes I force an update after every inspection routine. I'd hate the thought of loosing 30+ pieces like you said. Not updating after each routine is like Russian Roulette. You might be fine but I am certainly not going to take a chance on it. I update it without the message box that asks if it is ok to update, again this goes back to my attitude of having the operator do it. My situation is not the same as yours. Here the CMMs are on the shop floor and the machinists load their parts and run them.
Yes I force an update after every inspection routine. I'd hate the thought of loosing 30+ pieces like you said. Not updating after each routine is like Russian Roulette. You might be fine but I am certainly not going to take a chance on it. I update it without the message box that asks if it is ok to update, again this goes back to my attitude of having the operator do it. My situation is not the same as yours. Here the CMMs are on the shop floor and the machinists load their parts and run them.
Craig
Craig
I figured as much. I can see why it is optional to update or not, but no way will I not update after I check a part. It is optional so that those with lower scruples can NOT send bad data to Datapage and can 'replace' the part with one that checks good and send that instead. No need then to go into Datapage and delete out a transaction, jst keep it from going in to it in the first place.
The decision not to delete the stats file when an error occurs was decided long ago. Since the file is ascii it can be read using WordPad. If the DB path is the only thing wrong (and this is the cause of the error just about 100% of the time) the user can modify it to the correct path and update with this information. The down side is the user could also change the data values or add new data values.
