ConveyorTech -- calibration process is ignoring $MEAS_PULSE input?

**SkyeFire** · October 11, 2017 at 8:49 PM

KRC4, KSS 8.3.17, ConveyorTech 6.0.0

Well, this is a stumper. After confirming that, yes, I need to wire $MEAS_PULSE[1] to my synchronization signal (and confirming that connection in the Drive Setup screen in WV), I set about performing the first conveyor calibration, following the instructions in the manual:
T1
Startup>Calibrate>Conveyor
Select Tool
Select Calibrate Conveyor
Hit Execute
Start conveyor moving
Pulse $MEAS_PULSE[1]

And at this point I get hung. I keep getting this animation of the conveyor, but the Calibration screen is stuck at Step 1 of 5 -- it's as if the Calibration program isn't seeing the $MEAS_PULSE[1]. But I can confirm that $MEAS_PULSE[1] is definitely going FALSE-TRUE-FALSE -- I even wrote a logging function in the SPS to confirm that the signal is being received.

The only other possibility I can think of is that the resolver signal is not being received by the robot. I don't have any errors on the resolvers or RDC. If I swap the cable to another resolver (I have two KUKA resolvers on this conveyor), I do get a positional-change error that can be cleared, but that's it. I've tried checking $SEN_PREA, but it's all zeros. Which seems odd -- isn't $SEN_PREA supposed to show the resolver values for the CT resolvers? Or is that not active until after I run CONV_ON()?

I've checked the resolver mechanically, and the shaft is rotating with the conveyor. Checked the resolver cables for loose pins, and swapped the cables entirely -- no change.

So... either the Calibration program is ignoring $MEAS_PULSE[1], or it's not seeing the motion of the conveyor resolver. Those are the only two ideas I have ATM. I'm open to any suggestions anyone might have.

DannyDJ · October 11, 2017 at 9:06 PM

Hello, I have only setup ConveyorTech on KRC2. There you had variable in MADA/machine.dat $LOOP_TYPE_ATTRIBUTE[7]=1(here 1 ($MEAS_PULSE[1] is being used,2 for $MEAS_PULSE[2], 4 for $MEAS_PULSE[3],...) was defined by default when installing ConveyorTech), with $SEN_PREA_C[1] variable you should see distance traveled by the conveyor after Sync signal is received.

But I don't know if the same varibles are applied in KRC4.

**panic mode** · October 11, 2017 at 9:07 PM

I believe I encountered the same thing...

Check in single variable monitor signal $SEN_PREA_C[]
if you see value changing - conveyor was triggered and resolver is following it.

If the value is negative, calibration cannot complete. In this case change sign of value for R_CAL_DIG (set ti to -3.0 instead of +3.0).

**SkyeFire** · October 11, 2017 at 9:17 PM

$SEN_PREA_C[] is all zeros as well.

Is there any access to the "raw" resolver data (without triggering any of the sync signals, just the raw resolver output)? I drilled down into the RDC Diagnostic monitor, but that doesn't show any change when the resolvers move.

Hm... I don't recall seeing this before, but if I have someone jog the conveyor (no synch pulses), I get a string of 26004 "Encoder error (position encoder)" error messages, but they keep clearing themselves without me hitting Confirm -- as long as the conveyor is in motion, that error keeps popping up and clearing 2-3 times per second.

DannyDJ · October 11, 2017 at 9:32 PM

Did you checked the mdrConveyor.ini in User\MotionDrivers folder? there should be additional setup for the ConveyorTECH, the same as on KRC2. And I would check KRCAxes.xml file if Sensor-ID are generated correctly by WoV.

**SkyeFire** · October 11, 2017 at 9:48 PM

Never heard of 'em. But I dug them up.

mdrConveyor.ini:

Code

[LinearConv1]
POSITION_TRACKER_ID=1
FILTER_LENGTH=10
DELAY_TIME=24.0
PATH_FACTOR=3.0
TRANSLATORY_VECTOR=1,0,0
ROTATORY_VECTOR=0,0,0
SEN_PREA_INDEX=1
FILTER_BASE=0
REACTION_TIME=12.0
TRACE_INDEX=0

Display More

Everything here looks okay, though I have to admit, I'm not entirely sure what I'm looking for.

And KRCAxes.XML:

XML

<?xml version="1.0" encoding="utf-8"?>
<!--XML file automatically generated by WorkVisual V4.0.25_Build0286.-->
<!--DO NOT EDIT-->
<KRCAxes xsi:noNamespaceSchemaLocation="../../../System/Common/Schemes/KRCAxes.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Version Label="">
    <Info Version="KUKA V8.3" />
    <Schema Version="1" />
  </Version>
  <Axes>
    <Axis ID="1" Mode="StandAlone" Coupling="false">
      <StandAlone Name="A1" />
    </Axis>
    <Axis ID="2" Mode="StandAlone" Coupling="false">
      <StandAlone Name="A2" />
    </Axis>
    <Axis ID="3" Mode="StandAlone" Coupling="false">
      <StandAlone Name="A3" />
    </Axis>
    <Axis ID="4" Mode="StandAlone" Coupling="false">
      <StandAlone Name="A4" />
    </Axis>
    <Axis ID="5" Mode="StandAlone" Coupling="false">
      <StandAlone Name="A5" />
    </Axis>
    <Axis ID="6" Mode="StandAlone" Coupling="false">
      <StandAlone Name="A6" />
    </Axis>
  </Axes>
  <Sensors>
    <Sensor ID="1" MeasureChannelId="1" />
  </Sensors>
  <MeasureChannels>
    <MeasureChannel ID="1" />
    <MeasureChannel ID="2" />
    <MeasureChannel ID="3" />
    <MeasureChannel ID="4" />
    <MeasureChannel ID="5" />
    <MeasureChannel ID="6" />
    <MeasureChannel ID="7" />
    <MeasureChannel ID="8" />
  </MeasureChannels>
</KRCAxes>

Display More

Here, I'm guessing that it's Sensor 1 that we're concerned with?

DannyDJ · October 11, 2017 at 9:54 PM

Thank you, yes this looks everything ok, the id's look ok... So it should take the $MEAS_PULSE[1] as sync signal and you should see path data changing in $SEN_PREA_C[1]. Maybe there is some bug and should write to KUKA, cause it should work out if you see $MEAS_PULSE[1] changing, it should accept the signal.

**SkyeFire** · October 11, 2017 at 9:55 PM

Addendum: when moving the conveyor, in either direction, with or without pulsing $MEAS_PULSE[1], I get a constant daisy-chain of Position errors -- first the error, then it clears and becomes the Acknowledge message for that error, then the Acknowledge vanishes on its own without anyone hitting Confirm (and the PLC is not rigged to send $CONF_MESS yet), at a very constant 500ms pattern. That's very odd behavior.

These are KUKA resolvers and KUKA cables, plugged directly into the RDC external-axis connector (and that option was installed in Germany before these robots were shipped, as part of the original order). And I've already tried swapping the cables and resolvers around, to no effect. So I'm pretty sure this isn't an electrical issue....

Further note: this is happening to both of my robots, that are connected to this conveyor (each one has its own resolver, but they're geared to the same shaft). So this has to be a design-level issue of some kind. Possibly something is mismatched between the WV hardware config and the actual resolver? AFAIK, KUKA resolvers are all electically identical, and are all 4096 pulses/rotation, but I can't claim to have encyclopedic knowledge of the hardware.

**panic mode** · October 11, 2017 at 10:01 PM

check if the cable shield is actually grounded to RDC casing.

DannyDJ · October 11, 2017 at 10:02 PM

That error message are really odd. In my setup, if resolver on the conveyor is moving, regardless if I do position tracking or not, I don't get any error messages, only if I disconnect the cable from the resolver, but that is ok in that case.

**SkyeFire** · October 11, 2017 at 10:09 PM

This message is, AIUI, supposed to occur if the resolver is moved while the robot is off, or while the resolver is disconnected. If I swap my two encoder cables, I can force this fault to happen.

I'll check the electrical grounding, but given that both robots are doing this identically, I really don't think this is an electrical fault. It really feels as if the RDC is seeing waveforms it doesn't expect from the resolvers.

DannyDJ · October 11, 2017 at 10:12 PM

Do you have some KUKA motor available and try hooking it up? I used KUKA motor from robot, only rewired the BRAKE of the motor to 24V and used the resolver part of the motor.

**SkyeFire** · October 11, 2017 at 10:15 PM

Confirmed, the shield on the XP7 cable is grounded to the RDC cabinet shell.

Unfortunately, I don't have any spare KUKA parts -- this customer has these two robots, and that's it.

**panic mode** · October 11, 2017 at 10:19 PM

but you could connect conveyor resolver cable to one of the motors on other robot and see if the flood of messages continues (then you will need to remaster that axis).

DannyDJ · October 11, 2017 at 10:22 PM

That is a nice idea

**panic mode** · October 11, 2017 at 10:27 PM

and maybe X7.1 is not connected properly to RDC. another option is to use next available RDC channel...

**SkyeFire** · October 12, 2017 at 1:28 PM

This customer doesn't have an EMD (of course ) so I'll have to hold off on hijacking a motor for now (yes, I could field-master the axis, but I'd really rather not -- I can have an EMD here next week).

I've checked the X7.1 connection to the RDC -- it's connected to channel 7 on both robots, and there's no obvious cable damage, loose wires, etc.

Since there doesn't seem to be any way to directly monitor the raw encoder value, I think I'll take a stab at O-Scoping that sensor channel and see what the input looks like.

**SkyeFire** · October 12, 2017 at 2:08 PM

Well, the O-scope was a bust. Using the predefined "Conveyor" trace setup, I got nothing but flatlines, even with the conveyor moving. Of course, there's no definitions for what those various traces really relate to, but it's a safe bet none of them are the actual resolver data.

Hm... after hunting through all the traces available in the O-Scope config, I'm stumped. Anything that might give me positional data is connected to A1-A6 -- there's nothing that looks like it might trace the raw encoder values from a non-axis resolver. Anybody know what the secret trace name might be?

**SkyeFire** · October 13, 2017 at 3:03 PM

...and now the resolvers work. I don't know why. But for some reason, after removing and re-installing the cables for the 20th (or was it 30th?) time, all the Encoder errors went away and I was able to start doing the Conveyor calibration.

Robotnic_89 · December 5, 2024 at 5:12 PM

Quote from SkyeFire

KRC4, KSS 8.3.17, ConveyorTech 6.0.0
Well, this is a stumper. After confirming that, yes, I need to wire $MEAS_PULSE[1] to my synchronization signal (and confirming that connection in the Drive Setup screen in WV), I set about performing the first conveyor calibration, following the instructions in the manual:
T1
Startup>Calibrate>Conveyor
Select Tool
Select Calibrate Conveyor
Hit Execute
Start conveyor moving
Pulse $MEAS_PULSE[1]
And at this point I get hung. I keep getting this animation of the conveyor, but the Calibration screen is stuck at Step 1 of 5 -- it's as if the Calibration program isn't seeing the $MEAS_PULSE[1]. But I can confirm that $MEAS_PULSE[1] is definitely going FALSE-TRUE-FALSE -- I even wrote a logging function in the SPS to confirm that the signal is being received.
The only other possibility I can think of is that the resolver signal is not being received by the robot. I don't have any errors on the resolvers or RDC. If I swap the cable to another resolver (I have two KUKA resolvers on this conveyor), I do get a positional-change error that can be cleared, but that's it. I've tried checking $SEN_PREA, but it's all zeros. Which seems odd -- isn't $SEN_PREA supposed to show the resolver values for the CT resolvers? Or is that not active until after I run CONV_ON()?
I've checked the resolver mechanically, and the shaft is rotating with the conveyor. Checked the resolver cables for loose pins, and swapped the cables entirely -- no change.
So... either the Calibration program is ignoring $MEAS_PULSE[1], or it's not seeing the motion of the conveyor resolver. Those are the only two ideas I have ATM. I'm open to any suggestions anyone might have.

Display More

Bit of an optimistic ask being that this post was some time ago, but did you get any definitive resolution to this?

I am having the same issue. Working with: KR C5 micro; KSS V8.7.5; Conveyor Tech V8.1.3.

Much the same as yourself, been over the manual a number of times and not getting the outcome I would expect. Cross-referred with the WV manual and C5 micro manual as well to see if I was missing something. Hit a bit of a wall with this.

$MEAS_PULSE_[1] registering the T/F signals from the sensor correctly and as I would expect when I query the variable directly. Have tried altering the WV installation across all the fast measurements input options; as it's C5 micro there's only 3 available FM inputs - tried them all. Doesn't seem to want to recognise the synchronisation switch being triggered when I run "Execute", which leaves it stuck at step 1, as you have said.

Zeroes on the resolver as well when I check $SEN_PREA[], but I expected this as I understand this won't show anything until synch switch is triggered. Seems to me that the synch switch is wired in correctly, FM inputs reading the measurement correctly, but that the ConveyorTech KOP is not reading off of the FM input despite being configured, I think, correctly on WV.

Thought I'd ask on chance you got a resolution before I get onto KUKA directly. Thanks.

ConveyorTech -- calibration process is ignoring $MEAS_PULSE input?

Advertising from our partners

How to see your Job Posting (search or recruit) here in Robot-Forum.com