kinetix 6000 mapc issue

rhys_m

Member
Join Date
Jun 2016
Location
kent
Posts
15
Hi Guys been a long time browser of these forums and they have helped me an incredible amount, however I currently have an issue that I can't seem to find any info on (even tech support couldn't really help)

Firstly I'll give an overview of the application, we have a filling machine, one motor drives the "turret" of the filling machine, we then had a normal three phase motor that would drive the dosing system. To keep these in time some very antiquated hardware would adjust a 0-10v signal to an inverter to keep a flag appearing in a set window. we have two of these machines

I then built a temporary rig to modify the machinery the hardware consists of:

1756 L61 cpu version 19.11
1756 M03SE version 19
2094-bc02-m02-s servo drive
Multi turn high resolution servo and encoder.

I have mounted the encoder on a shaft connected to the turret, then via use of a MAPC instruction I have the servo motor driving the dosing in time with the turret. I am using a linear cam profile from 0-360, with a master lock position of 287 (this is the controlled stop for the dosing)

Now this works perfectly fine with absolutely no issues what so ever.

So we have gone ahead and ordered the following

1756 L71 version 24
1756 M03SE version 19
2094-bc02-m02-s servo drive
Multi turn high resolution servo and encoder.
Panelview plus 7

So I copied the program over, changed cpu and version etc etc. Intalled this to the second machine (this has slightly different stop positions) and I now have a very strange issue.

When the panel is powered down and back on, and the MAPC is executed the servo drive trips on either overspeed fault or position error. After trying almost everything I could think of I wired a second encoder off the machine and turned this by hand to see where the fault was happening.

It turns out that even though I have the Master lock position set to the current position of the servo (under normal conditions this is 302) it will attempt to lock the cam profile as soon as the encoder hits 0 degrees, therefore instructing the servo to move all the way to 0 and causing the above errors.

now for the really weird part, the encoder is holding its position after power up perfectly, but if I home the encoder (no change to the position reading as its always spot on) then it will run with absolutely no issues at all, until it is powered down and back up.

Ideally I would like to sort the above issue out, however I have though of a work around but I'm not entirely sure how to implement it, what I would like to do is, read the position of the encoder after power up, then use this position as a home offset and then perform a home, this way it retains its position, but will be homed and wont cause any issues, but the only place that I have seen the homing offset is in the homing tab, and I would need to be able to dynamically change this value depending on the encoder position on power up.

Hopefully that makes sense, and someone could give me a bit of guidance I cant upload the program as its over the limit, but if someone has a trusted site I can upload to I would be happy to.

many thanks in advance

Rhys
 
Somethings to think about
I am assuming that the turret is set up as a rotating 360 axis
this means that the 360 axis always rotates forward and eventually the multi-turn encoder will rollover

  1. Do you ever home your encoder?
    If so what method do you use? - In your case an Absolute Home is best if the offset can be stored in the encoder.
  2. Is the scaling ratio an integer multiple of the multi-turn encoder?
    What I am looking for is when the multiturn encoder eventually rolls over followed by the next power cycle it may "position jump" if there is not an exact ratio of turns
  3. When you downloaded the new program why did the M03SE firmware not get updated?
    I thought that the motion software had to be lockstep with CPU firmware
  4. Before the MAPC is executed is the axis.actionstatus set?
    ie Has a MSO been successfully executed?

Check out the MRP instruction - position change without homing
 
Last edited:
Hi many thanks for the reply

1: We do home the encoder, I have it set to absoloute. The system will only run if the encoder has been homed, even though the position reading before and after the home was/can be exactly the same.

2: I have had to use an mpl servo as the encoder (sounds silly but our preferred supplier only has a £1000+ encoder for sale and an mpl-B220T-VJ72AA was round £600) I have set the scalings exactly the same as the servo except that everything on the servo is x10 as its using a 10-1 gearbox. however you can start the system up, it will fault after say one revolution. I can them home it, it will then do one revolution fine. I can then stop it, power it down, then back on. It will them proceed to fault every time until a home has been completed. so it wont be close to the 4096 turns. (If I am understanding what you are saying correctly)

3: this was a typo on my half both are v24

4: I have the MSO operating correctly for the servo drive, however I do not believe I have one for the encoder (this is plugged into the aux port on the drive, and set as feedback only)

Could I perhaps do the following on power up.

  • Read position of encoder
  • Store into a REAL value
  • Home the encoder
  • Then copy the original posistion to the MRP
  • Execute MRP and hopefully keep the encoder "homed"

I have been looking through the release notes and compatibility checks for the 6000 drive, however im not sure if any relate to the firmware we have (v1.120) I have found a few

This is a restriction related to all firmware

"The auxiliary encoder channel does not generate a marker from any sine/cosine device, including SRS/SRM feedback"

Which is an issue I do get when every I do the marker hookup test.

This one doesnt apply to my firmware but makes me suspicious that it could be a firmware issue with something on the set up (the original test installation was using 3 year old + plus parts from stores, this new setup everything has been ordered in)

Corrected Anomalies with Revision 1.129
Cat. No. Description
2094-xCxx-Mxx-S and 2094-xMxx-S
CORRECTED: Loss of absolute reference status after power cycle for feedback-only axis.
Lgx00149184
IMPORTANT This anomaly was introduced with firmware revision 1.127 and is not present in earlier
revisions.

Many thanks for any help

Rhys
 
So I think I have successfully figured out a work around for this, however if anyone has any insight to the actual issue still then that would be greatly appreciated, I have attached how I think I have got around the issue, I dont see any reason that it wouldn't work, I was going to use the MRP function however I'm not sure if this will clear the homed bit and then make the cam play up again. So I have gone through the SSV route to set the home offset to the actual position of the encoder. At the end it leaves the offset back to 0 so that the maintenance guys can do a normal home if ever needed.

I cant test this until monday so if anyone sees any potential issues then please let me know

I have never used the GSV and SSV instructions before (except for time/date) and since doing the above I now realise just how much can be done with these

home1.jpg home2.jpg home3.jpg
 
Using the GSV/SSV to load the actual position of the encoder into the home offset of the axis is the cleanest way to do it, IMO. Having to home, then MRP would probably work, but is a kludge.
 
(y) thought so much, thanks for the assurance

One question i do have, from the screen shots I have used the drive_enable bit to begin the sequence, am I right in thinking this is just from when the drive is ready to go (ie booted up to number 4) or is this actually when you close the servo loop?
 
(y) thought so much, thanks for the assurance

One question i do have, from the screen shots I have used the drive_enable bit to begin the sequence, am I right in thinking this is just from when the drive is ready to go (ie booted up to number 4) or is this actually when you close the servo loop?

The .DriveEnableStatus bit is the same as the .ServoActionStatus. And yes, it means that the loop is successfully closed. The servo is under torque control and holding position. I'd have to dig in my notes, or someone else may chime in, to say which bit indicates the fully booted status.
 
ah ok, it will work fine using that bit for now, however it would be alot more fault proof if I could use to proper bit, I know that the drivestatus bit is sat at a different value to 0 when its running so maybe its one of those, I'll try and do a abit of research.

Thanks again (y)

Rhys
 

Similar Topics

Howdy guys - Looking for some insight on the MAM instruction. Had an interesting one today: I performed a controller upgrade on an older system...
Replies
1
Views
398
Hello everyone: I am looking at the possibility of migrating Kinetix 6000 to Kinetix 5700(460V 3 phase). Reviewing the drive catalog, I have the...
Replies
4
Views
1,043
We have two similar pieces of equipment, one of them uses a Kinetix 6000 for an axis and the other uses a Kinetix 350. When power is removed...
Replies
1
Views
819
Hello All I have a machine built in 2013 but never commissioned. I have it almost complete. It has 2 Kinetix 6000's with a CompactLogix L43 with...
Replies
6
Views
1,183
Trying to configure the 2nd drive on this machine. It is being difficult. I have the gains speed encoder data all with good data. when I try to...
Replies
8
Views
1,798
Back
Top Bottom