1394 actual position problem

Hey guys, the other nite I had a problem with a 1394 drive. The fault labeled in the PLC, which was a slc, by the way, was labeled in the program as an Actual Postion Feedback fault. The machine runs in a circular motion, and the center turntable is called the Dial. We are using the 1394 as a sort of cam postioner, in that we use the position feedback from the drive to trigger events to happen when we need them to, such as to check for a part, etc. The problem I had, is that home position is 0 degrees, and halfway around the turntable is 180 degrees. However, upon making a whole revolution, instead of returning to 0 degrees, the input word I was watching would keep adding the current position to the old. In effect, 90 degrees now read in the SLC as 450 degrees. Because of this, none of the logic would execute, because we were looking to check for a part between 75 and 115 degrees. I know that this word I was watching comes from the GML program, but I cannot find it there. I am also pretty sure that somewhere in the GML program, there should be something telling this position to be reset to zero. My question is, is this normally done with a function block in the GML program? If not, how do we accomplish this, and why would it fail so intermittently. After powering down the drive and back up again, the position was reset and never missed a beat. It has been a week. Any insight would be appreciated if anyone else has seen this. I am wondering if there is a better/simpler cure for this problem than powering down the drives, perhaps manually triggering whatever is used to reset the postion to zero. Thanks in advance for any insight.

Russ

Probably not the reason, but I'll take a guess...

The position might get reset to zero with a compare statement. IOW, when you reach 360°, reset current position to 0°. The programmer might have used an 'equal to' (EQU) rather than 'greater than or equal to' (GEQ) statement to reset the position.

If the machine's running slow enough, the PLC will always get to see the number "360", and reset the position. If you went faster, or if the PLC was 'busy' with other stuff, it may have missed seeing "360" and therefore not reset. If you miss the 'window', you're screwed...

That's blatantly lousy programming, so I doubt that's it. Then again, I've see some really poor programs in my time, so anything's possible... utoh

beerchug

-Eric

P.S. Pardon my ignorance, but what's a GML program?...

Eric,

First, to answer your question. GML is software put out by AB used to run the 1394 drives. We currently use version 4.03. This was before the 5000 came out, I believe. It is really different, and I don't understand a lot of it. I guess now seems like a good time to learn. Back to my question. What you are saying is that the reset instruction would be located somewhere in the SLC logic, correct? It is my thinking, although I am not sure, that this position number is calculated in the drive, and written to the SLC. Therefore, I do not think that this reset is done in the SLC, as if it were, the number would be changed to 0, rewritten from the drive, changed back, etc. I am not sure about this though. I am also not sure that the reset instruction does not come FROM the SLC, to the drive saying reset to 0, then get sent back to the SLC for comparisons. I was just looking for a little insight as to how this application is typically run. I do know that the input word I:7.2 is the input word from the drive in which the position is listed. From there, it is copied to a FLoat register. THe float is then used to do the checks for different things throughout the cyle. Thanks for the idea though. I will look thru the SLC program harder for some sort of a reset instruction. Any other ideas from you or anyone else are more than welcome. I have spoken to my seniors about this, and they said it has been a problem for several years, though very intermittent.

Russ

Eric- you could subtract 360 whenever you see the position greater than 360. It won't matter if you overshoot.

It has been a while, but isn't there a way to define an axis in GML as rotary? There should be a value called 'modulo' or some such to tell the servo how many units in a revolution. I am going to check now.

I found it. Go into the axis definition and change the linear definition to rotary.

I missed the part in you post that it is intermittent. Now I am confused. Are you saying that it resets to zero most of the time?

Is this a new machine?

If your "axis use" is set to be rotary motion, you have some options for move type in your move blocks: rotary positive, rotary negative, and rotary shortest path. What is the move type in the block that you are having problems with?


I would call the servo's full rotation 360 degrees instead of two 0-180's. It doesn't sound like they have done that.

Would it be possible to zip and post the SLC and GML programs?

The position can be reset in GML

russrmartin said:

Back to my question. What you are saying is that the reset instruction would be located somewhere in the SLC logic, correct? It is my thinking, although I am not sure, that this position number is calculated in the drive, and written to the SLC. Therefore, I do not think that this reset is done in the SLC, as if it were, the number would be changed to 0,

Click to expand...

Most likely the position is calculated and "reset" in the GML. It would be possible to do it in the SLC but it doesn't seem worth the work when you have a $12,000 servo drive that's more than capable of it.

The "redefine position" block is the simplest way to "reset" the servo's position. This block can redefine the current actual position to 0, or any other position.

Two ways to do this

I've used the 1394 and GML on 20+ axis. There are two ways this can be done in the 1394. The first would be to program the axis as a rotary (like 93lt1 said). Then on the feedback page of that axis configuration there is an unwind constant and an unwind reference. This will determine when the units should be reset and what they should be reset to.

The second way is to use a linear motion and call out in the GML program to reset the actual position when ever the actual position is greater or equal to 360. This is similar to what Eric mentioned, but it can be done in the GML code using another task.

In our GML code we have had problems were if multiply tasks are running, one task might stop and discontinue to run. This task is usually task 0. This has been intermittent, but usually happens right after a power up. We have never figured out why this happens, but we learned to put a dummy task 0 in the program that does nothing.

If you press the reset button on the 1394 controller, the GML program should reset and start over. This works the same as powering down and back up, but then the reset of the system can stay running.

If you post you GML code, I can look it over and see if I can see any insight.

Good Luck

Getting somewhere

First, thanks to all for the help. Now down to business.

1.Rick, the axis is configured as a rotary axis. And yes, almost all of the time the position is reset to 0. This problem happens once every few months, and nobody here can explain why.

2. 93lt1, this is not a new application. We've had the machines for about 5 years I think. I have yet to find what move block I am having problems with. I guess, in effect, that may be my main problem. After reading the previous posts, I do not believe that this is done with a move block, or the redefine postion block.

3. Craig, it appears to me like we are resetting the postion to 0 the way you described in the final post before mine. In the axis configuration, there is a conversion constant of 80, an unwind constant of 28800, and the unwind reference is 0. So, I think it would be safe to say that the way you described as your first way, is the system we are using. You also made me smile when you described the task 0 stopping after a power up. This is exactly my whole problem. When we get out of whack with the axis position, the only way we have known to reset the position was to power down the drive. This occasionally causes the GML program in the drive to stop, forcing us to hook up with a laptop and restart the program. Often enough, we cannot even get online with a laptop for whatever reason. I have found that the only way to communicate with the drive is to wipe out the program by pressing the reset and initiate buttons simultaneously. Then, once online, we can download the program, start it, and finally walk away. I am searching for what causes all of these problems, one at a time, starting with the actual position problem.

I believe that you hit the nail right on the head with the tasks stopping. The last time we had this problem, the position of the axis in question was in the 7000 range. This should NEVER be above 360, which means to me that this task is not executing. Do you have any idea why this would happen? I can't tell you for sure if this happens all the time directly after a power up. However, I would like to know how you put a "dummy" task 0 in the program. I am unfamiliar with this, but from what you describe it sounds as if it may cure a lot of my problem. I don't have the time now, but I will try to post the GML later on. Thanks again to all.

Russ

GML program

Hopefully this works and all can see the program I am working with. It is a zip file, it should have everything there.

Russ

Attached is what I did in our GML program. Not sure how to paste a picture. The first task block will pass task 0 straight through and this task was the one we had problems with. It didn't matter what was in Task 0, but it was the only task that stopped running. I made task 0 just an equation that set a variable to 1. In the PLC I would use this as a watchdog and reset it after seeing it on. If the bit never went one again, I knew there was a problem. I am not sure why our task 0 would stop running, but it I don't see anything else wrong with your code.

I notice that the axis 3 called "dial" is set up as master only, not servo. What drives this axis? What are the other three axis?

IS there an eye that tells the "dial" that its "home" ?
Is the machine setup using the registration input on the 1394?
Just a couple things that come to mind.


Drewcrew6

Regarding not being able to get online with the 1394 I've had problems getting online when the SLC is commanding the 1394 to run through the Turbo Interface. This is done with SLC output bit O:n.0/0 (looks like in your case n=7). I have written lines in the SLC code so I can go online with the SLC and flip a bit to stop and start the 1394 program. In this example, B3/50 is used to control the running of hte 1394 program. Note that I do not write an output instruction for this bit. I only use it when online where I can toggle the bit to control the 1394 program. I haven't had a use for the pause program bit so I just unlatch it.

CTL_1394_PGM                RUN_1394_PGM

  B3/50                       O:n.0/0

---] [--------------------------( )----





CTL_1394_PGM               STOP_1394_PGM

  B3/50                       O:n.0/1

---]/[--------------------------( )----



                          PAUSE_1394_PGM

                              O:n.0/2

--------------------------------(U)----

Also, in my case, I have been using a 5/04 and communicating w/ a PCM/K card over DH+ to the SLC. I have noticed that if I start communicatons with the SLC first, I have problems communicating with the 1394. If, on the other hadn, I first set up communications with the 1394 (over a serial cable to COM1) and then talk to the SLC things work much better.

As far as your position problem, the only thing I could find was that in your Home Mode, you have a redefine position block that sets the dial position to an M0 variable that is coming from the SLC (M0_dial_home_position_sp at address 20). Perhaps there is a calculation gone haywire in generating that number? I would check for what generates this number in the SLC. Maybe write a flag output if the value goes out of range. I don't know how the 1394 will react if you set a rotary axis to a value greater than the rollover value? Anyone have a test system to check this out on?

Note to 93lt1:
A master only axis is basically an encoder plugged into the controller with no associated servo motor (at least not one controller by the 1394. You can slave or gear another axis to it or just look at the encoder value and drive e-cams off of it as Russ is doing.