Want to help catch a cheater!!!!

Good morning all,
It's been a while since my last visit. It's been busier at work, new boss, etc... Anyways, I'm a maint. tech with some experience with PLC's (school, in the workplace & built PLC sim), but not fluent like most of you. I am wanting to catch the crook that is on 2nd shift that is making my shift and 1st look bad. I am looking to get proof that the tech or operator is zeroing out the rejects somewhere within their shift to produce a lower scrap rate. Last night we ran 1.19%, dayshift followed with a 1.20%, then 2nd ran 0.22%, we come in and running about 1.00%. Shaaa haa Sure they ran 0.22% and I might have monkeys fly out of my butt! What I want is one of two things (unless you know another way):
#1 Basically save the Excel file of the pc monitor that everything is stored on, every 1.5hrs, copying the info and pasting it way below, out of sight and 1.5 hrs later, paste it below the last one and etc.... (You should know that the operators press a button to save the sheet at the end of the shift) and then a new sheet is ready for the new shift.
#2 idea, is to modify the logic to compare the reject qty. everytime a good pc is accepted. If the rejects decrease then capture the accepts and rejects prior to the clearing of the reject counter. The timers can start when the shift starts by pressing a reset good parts counter (on the panel mate).
I don't know what may be easier. I don't know if our programmer will have time for this with running 2 bldgs, but I always run everything by him of what I did if I modify something. We are the only two allowed to modify the logic. I can't remember when you do a move, it's really a copy right and not a move (like a cut and paste), correct? Some info is derived from the PLC and some from Excel. I am going to include a saved copy of the excel spreadsheet and have changed some of the test names just because the company would not appreciate it. The blue areas are just text stuff, the green is calculated using excel and the orange are realtime from the PLC (Slick 500). I included in parenthesis' what the cell contains for its formula and such. You will see a pattern of the blues and oranges and therefore I didn't fill each cell. In a nutshell I need to know what the accept good pieces were when the rejects go back to zero & affix them to that spreadsheet, or better yet what the rejects were before they went to zero. I probably wrote too much and I'm sorry for that, just trying to leave nothing out. Since pay raises also is based on the info of scrap, downtime and production, all of us on 3rd want to prove what we know.
Thank you very much
Dr.Oldz

Cheater

If our are looking at good parts/bad parts, I imagine you are using some type of counters. Could you not just add some other counters that could only be reset from inside the program. Then just come in the morning open the program and see if they match your production counters. You could also use the PLC Time if you only wanted to look at a certain shift.

I was thinking along those lines. Simple thing is do a 24hr total with separate counters that cannot be zeroed...this assumes a tech can not access the program and change via software.

Personally I wouldnt attempt to put anything into Excel. I would just create redundant counters etc as Mark mentioned and bury them in the program. As Mark stated you could use time to trigger when the counters started if necessary.

If you find that the shift is tampering with numbers then you can goto management. I would think a redesign of the software would be needed so no shift could "rezero" rejects without a flag or something occuring, especially if it can be done with a pushbutton.

Then again if you have a "smart" tech that is connecting with software and is paying attention then it may be hard to catch. If he is using his own laptop and connects after changes have been made his offline copy will not match so he will know changes have been made and can look for the changes.

Keep it simple so its harder to find, once you have the facts then go from there.

Or just move the values into a Data Block every xx minutes...

Then you would see the values increasing and suddenly being reset at a certain time. Depending on how many minutes you wait before 'moving' the value into the data block you should be able to work out when the reset happened...

PS. I'd be very careful how I approached something like this for two reasons..

a) You don't want to mess up something within the code and cause a load of downtime/rejects on another shift. It would then look like you were trying to sabotage the other persons shift..

b) It just might be that the figures are correct. Be absolutely sure before you stick your neck on the line or you could end up with egg on yer face (two cliche's in one sentence.. not bad).

Good luck

These are all good suggestions, the programmer and myself are the only ones that know anything about PLC's. I've offered to help some time back and not one taker. If he goes on vacation I step in if anything happens. I shouldn't have to bury it deep, but I will ask him if he has time (as a courtesy) and if not, I think I will do as suggested and keep it off the sheet and in the program. No one else knows about this so I can catch this, if indeed, it's happening. This seems to happen way too often though, where 2 shifts run x% and 2nd runs at half that amount and then we come in and run about where we were the day before. Thanks for the input and if anyone else has ideas I'm open to them. I would like to get this in place before the weekend if the programmer don't, when it's less supervised. I will write back and give the results of what I find. Thank you very on behalf of 3rd shift (and 1st, even though they won't know what I'm doing)
Dr Oldz

Just out of curiosity, what are the times that your shifts work? Is there any possibility that the counter is being programmatically reset at the stroke of midnight with second shift ending shortly thereafter?

Just a thought.

Jeff

As JohnnyT said - it might be that the figures are correct.


I used to work at a place where the 2nd shift (we ran two 12 hour shifts) always had a higher yield than 1st shift. It turns out the the 2nd shift operator was much more knowledgeable in the field, but had gotten frustrated trying to convince the day shift operator that "his" machine settings were better. So - he would come in at 7:00 PM, by 8:00 PM he would have the machine adjusted to "his" settings (running more efficiently), by 6:00 AM he would adjust the machine back to the "1st shift" settings, and by 7:00 AM he would turn the line back over.

Marc

If your using an SLC use a COP instruction set as follows

Source #N7:1

Dest #N7:0

 

Length 128

Then if you move you counter value to N7:128, then trigger the COP instruction it will log the value ,I use it to log down time on our plant you could set it up to log the counter value every hour.At the moment I have 4 months of values logged on the PLC.

I don't know if I'd want to mess with the PLC program if I didn't have to. Personally, I'd put together a little VB program that runs in the background and periodically logs the OPC values that you're interested into a text file.

It wouldn't be a trivial thing to do and would (obviously) require access to Visual Basic, but it might be a good learning experience.

If the Buttom is hooked to the PLC than set a timer to not allow the buttom to reset every x hours. Once you push it you can't push it again for x hours.

Along the same lines as Rich's idea...

Password protect the reject counter reset. Each shift has their own distinct password, which can only reset the PREVIOUS shift's count value. IOW, 2^nd shift resets 1^st shift's counter, 3^rd shift resets 2^nd shift's counter, and 1^st shift resets 3^rd shift's counter. Keeps everyone honest.



-Eric

I like Eric's the best so far. It keeps everyone honest without pointing fingers at anyone directly....

You could always couch it in legalese verbage;

"A new policy is going to be enacted...blah,blah,blah"

or try to make them look bad and see if they like their own medicine ;-)

for example keep saving counter to another register.
on a rung above it check if the two differ by more than one count.
if so just add 0.3% or whatever to the calculated average.
this way the result will keep on growing regadless if they put bigger
or smaller number.

Last night we ran 1.19%, dayshift followed with a 1.20%, then 2nd ran 0.22%

Click to expand...

I vote that you do nothing.
I'm pretty sure that the production manager can see the disparity.
It's obvious who's fudging the numbers.

Petty bickering between shifts is sommething that drives me nuts.
Probably your boss too. You may find yourself getting into more trouble than it's worth.

Now if this person is doing something that is dangerous to other employees or damaging to company property, then I'd report it.
Otherwise Eric's idea will probably work well. Put it in the suggestion box, but keep quiet about the 2nd shift yahoo.
Your boss already knows.