News:

  • June 09, 2026, 02:49:07 AM

Login with username, password and session length

Author Topic: Machine overshoots  (Read 31831 times)

mo2004

  • Jr. Member
  • **
  • Posts: 14
Machine overshoots
« on: February 13, 2008, 04:03:46 PM »
The program was done in stage style programming.
Sometimes when the operator takes the machine into pause mode by hitting the pause button and then clearing the pause condition. The machine overshoots and does not return to normal operation. I suspect a faulty CTRIO card.

The problem is this condition is not happening every time the operator initiates the pause stage.

What you guys think, I appreciate any help.

Greg

  • HostTech
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 702
  • Hmmm...
    • Host Engineering, Inc.
Re: Machine overshoots
« Reply #1 on: February 14, 2008, 04:19:23 PM »
Sorry mo2004  :(, but there really is not enough technical information in your post to offer an opinion as to what is happening to your machine. Since we designed the CTRIO card, we would need to know how it is configured (both hardware and software), and also how it is used in the ladder program itself. Any further information you could offer would be a big help.
There are two types of people in the world; those that can extrapolate from incomplete data sets.

mo2004

  • Jr. Member
  • **
  • Posts: 14
Re: Machine overshoots
« Reply #2 on: February 18, 2008, 11:13:46 AM »


Sorry for the lack of the information I am knew to all this:

□ The CTRIO is set up to run in the Run TO position mode. I believe the reason for the machine not responding to the pause is the CTRIO is not suspended by having the pause input initiating the

□ B2056.2 Suspend output (SET).

□ When the operator takes the machine out of pause the CTRIO is not paused and it was running through the time when the machine was paused.

□Would the missing B2056.2 (SET) cause for the machine unexpected overshooting coming off pause mode.

thank you all.

Greg

  • HostTech
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 702
  • Hmmm...
    • Host Engineering, Inc.
Re: Machine overshoots
« Reply #3 on: February 19, 2008, 11:53:50 AM »
Assuming your mapping for Outputs is V2030-V2061, then B2056.2 would certainly be the Suspend Output bit. If this bit is SET (ON), then the CTRIO immediately stops output. It could be if the operator is using an HMI device for the "pause button" which then in the ladders gets translated to a SET B2056.2, that there is some delay in communicating to the PLC this button press from the HMI. You might want to test the machine using DirectSOFT's Data View and verify when the operator presses the "pause button" that this bit gets set. Or you might want to set the bit manually to see if the CTRIO stops. Or is the CTRIO stopping, but the momentum of the machine carries it forward further?

Does this help?
There are two types of people in the world; those that can extrapolate from incomplete data sets.

mo2004

  • Jr. Member
  • **
  • Posts: 14
Re: Machine overshoots
« Reply #4 on: February 19, 2008, 04:23:43 PM »
The pause button is an actual button input to the PLC.

the strange thing is this happens some of the time and not all the time.
for example i could test the machine BY taking it into pause and off pause and see it working properly (b2056.2) .
and all off sudden the condition happen again

Greg

  • HostTech
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 702
  • Hmmm...
    • Host Engineering, Inc.
Re: Machine overshoots
« Reply #5 on: February 20, 2008, 10:44:59 AM »
Since you said, "The program was done in stage style programming", I suspect it has something to do with this, because I have never heard of a CTRIO not reacting to this bit. To attribute that to the CTRIO would be weird indeed  ???. So, I'm guessing that perhaps the input turns ON, but the stage where that particular rung exists that SETs the Suspend Output bit is not being executed immediately (or not at all) at the particular time the operator hits the button... or something like that. I have seen many more issues with strange or intermittent symptoms that were due to stage programming rather than failing hardware. But... I've been wrong twice today already.   ;D
There are two types of people in the world; those that can extrapolate from incomplete data sets.

mo2004

  • Jr. Member
  • **
  • Posts: 14
Re: Machine overshoots
« Reply #6 on: February 20, 2008, 12:07:33 PM »
Greg,

Thank you for inputs. I am going to try and trouble shoot the problem in the stage view. And see when the fault occur which stage is on.

I let you know how it goes.
 :)

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Re: Machine overshoots
« Reply #7 on: March 01, 2008, 07:51:28 PM »
This maybe a little late, but I had simular issues at the start. I found out the signals were so fast, I had to put in timers before I looked at certain bits. Like the bits to confirm loading etc. I had to seperate into more stages to wait for signals to clear or set. The more I broke up the program, the better it got. The one program I am running works really well after breaking up into more stages.

mo2004

  • Jr. Member
  • **
  • Posts: 14
Re: Machine overshoots
« Reply #8 on: March 18, 2008, 12:36:03 PM »
Sorry i am late
what bits did you have to use timer with