RSlogix data files...

I had a belt that conveys brick with multiple moves, stops and runs.. Each brick which is different has a different product setup for certain pulls and move lengths.

Now basically at the end of the groups shift this belt would no longer run in automatic nor would it jog in manual mode from the HMI screen. But I was able to move the belt via MoviStudio (Movidrive Inverter to Sew motor) and with the DBG pendant.

Short of the story was that in Rslogix MOVE file the plc basically zerod out all the moves. The HMI screen had all zeros for moves also. But the actual parameter tag list was perfectly fine with the correct positions.

My question is how can this happen other than someone manually adjusting all the moves on the HMI (honestly the operators would NOT do it, I am serious) It was a on day when it is possible the power for the plant flickered. But there is no other indication of other parameters being lost.

Once I changed the HMI to a different style of brick the new move parameters where put in for that brick and the belt worked just fine. But at the same time the ZEROS in the move files moved to the Serperation moves 16 tag.

I had to download an older version of the program (1 day older) with the correct values to fix this issue.

This pictures are after I fixed the issue.

I have had a Panelview zero out values on the screen during a brownout/ lightning strike, and since those values look like they are 'new' they were written to the PLC5. But that was *YEARS* ago.

A more modern recipe editor, like those built into newer HMIs ... where you change values and then press a button to send the data to the PLC ... should not do things like this.

A power filter on the HMI and PLC would help. A UPS would be better. And protection on the communication lines (ethernet, serial, devicenet, etc)

thingstodo said:

I have had a Panelview zero out values on the screen during a brownout/ lightning strike, and since those values look like they are 'new' they were written to the PLC5. But that was *YEARS* ago.

A more modern recipe editor, like those built into newer HMIs ... where you change values and then press a button to send the data to the PLC ... should not do things like this.

A power filter on the HMI and PLC would help. A UPS would be better. And protection on the communication lines (ethernet, serial, devicenet, etc)

Click to expand...

We did have a power failure that day, during working hours for the operators (after I was gone) My Electrical Engineers told me to just not worry about how it happened cause they couldn't know how. Thus Why I was asking the forum for some reason beside electrical interference. OFC they said yes that could happen but still...
I just don't like to be BEAT I want to figure out WHY and FIX it. Since my EE are company and they are always traveling and what not and I work 3 plants.
Thanks THingstodo

What onscreen objects can change those position values ? Is it just the increment/decrement buttons ?

Are the position values read/write to the PLC, or do they only come from a parameter file inside the HMI ?

There is unseen logic and 2-dimensional UDT arrays, so I suspect there's a chance that a power glitch or input condition interrupt might have confused some upstream logic that ordinarily sees nice constant status inputs.

Ken Roach said:

What onscreen objects can change those position values ? Is it just the increment/decrement buttons ?

Are the position values read/write to the PLC, or do they only come from a parameter file inside the HMI ?

There is unseen logic and 2-dimensional UDT arrays, so I suspect there's a chance that a power glitch or input condition interrupt might have confused some upstream logic that ordinarily sees nice constant status inputs.

Click to expand...

YES Just the buttons Ken. Yes read/write. The initial values where written when we made the product set up. but it can be adjusted via the buttons via hmi screen and written back to the file. and so on.

Thats my only guess was that the info just got lost in translation literally when from or to the hmi lol

Short of the story was that in Rslogix MOVE file the plc basically zerod out all the moves. The HMI screen had all zeros for moves also. But the actual parameter tag list was perfectly fine with the correct positions.

Click to expand...

Does this routine contain one shot bits?

It sounds like the power lost and power up conditions could have caused a false to true transition to trigger a one shot and to clear out the positions.

Retentive versus Non-retentive data?

I have a PLC system which, on a power failure, it comes back with random
data. (I create a new job, send it out, start and end the job and all is
well with its world again. An UPS fixed that problem.)

Possibly something non-retentive went to zero on the power loss, then
'cascaded' through the system zeroing out the parameters?

Poet.

The person who wrote this programs uses BSL to sequence the steps in which it stores and restores the data.
I was able to put a test bit in the restore data rung. This same issue happened 2 days ago and with this bit I can just restore the #'s without having to redownload the program. I am still researching this issue as it just came about.