CANBus and UNICAN

[lawry]

Hi,

Is there an example which could point one in the direction of using both CANBus (to read from a Kubler Absolute Encoder) and UNICAN (to have communication between a V1210 ans a V130) simultaneously?

 

Any help in this regard will be highly appreciated

 

Thanks

 

Lawry

[lawry]

This is an urgent appeal for help.

 

I have a V1040 which is Stationary, a V130 which is mounted on a lift and a Kubler 8.F5868.212F.2123 Absolute Encoder. The Lift travels a distance of 50 meters in the vertical direction. I have earlier asked for some pointers in the use of both CANOpen and UniCAN, but to no avail. My system works fine for some time & then i either lose comm between the V130 or the Encoder or both.

 

How do i avoid this. What would the best sequence of switching be?

 

Please Reply ASAP

 

Thanks

 

Lawry

[cantcliff]

Lawry,

 

If the connection is clean, you shouldn't have drop issues. 

 

You could try dropping the communication rate to a lower speed.  I would also check the terminating resistors at each end of the bus.  Another potential problem could be your shielding, double check you don't have a ground loop condition and that at least one end is properly grounded.

[Ausman]

Hi Lawry,

 

+1 to all that cliff suggests.  I have some more possible pointers, some of which might not work but come to mind as something to investigate without knowing the full system.  And apologies for suggesting stuff that you might already have in place.

 

1).  Chased your encoder and it looks like it has many parameters that are programmable, one of which seems to be termination.  So as with cliff's termination resistor pointers, check it is correct.  Probably easy to miss.

 

2).  How is the flexible connection b/n the 130 and 1040 achieved?  Is it through a line "dangle" or a commutator system.  Either way, perhaps there is an intermittent connection issue there, which could be a devil to find.  If all else fails, perhaps duplicating this link might help.  If it is a rotary draw commutator system check it over very carefully, consider changing to a mercury based one if possible.

 

3).  Consider changing the Encoder to something else that lets you use the high speed inputs on the 1040, instead of a bus system encoder which might be confusing things at present.  By the sound of it you are running both unican and canopen, I have never done this and perhaps it is hanging together most of the time but then cracks the poops for some silly reason.  Different input encoder might cure this as it is then only running one bus.  Might also have a side benefit of making your positioning better as it will have quicker reads.

 

4).  I'm assuming that there is a limit switch system in place for initial location setting by the mechanism on cold booting. So as an auto reset, you could fit another input from the drive system that registers movement, like a simple inductive, that then sees if it roughly matches what is supposedly happening, via programming.  ie  my drive is meant to be working...the inductive shows there is something going on but the encoder says zip = error.  If it throws an error it initiates a full reset and the system will fix itself at the time.  Not ideal, but would keep things going.  I have this double check sort of system on all my projects where this sort of operation happens.  You can also log the parameters at the time and this might point you in a good direction, as something might appear.  eg it consistently drops out at around 24 metres.

 

5).  Do the same reset thing with the 1040 and 130, with each of them having an internal counter reset by the other to check if the comms are still in place correctly.  If they fail the test then like in 4) it triggers a total system wide power reset run by an external timer for 10 seconds, say, initially triggered from the plc.  (edited this last for clarity)

 

6).  Good luck.  Intermittent faults are a right PITA but you can do some things to make the job of finding them easier.

 

cheers,

Aus

[Ausman]

Me again,

 

perhaps also link your bus error bit to a distance logger, being another check to see if it is a failure due to a particular distance.  At present it might be mostly riding through a dud zone on a few retries and very occasionally getting caught out, but if you log every comms failure, it might help isolate it.

 

cheers,

Aus.

[lawry]

Thanks Ausman.

 

1. The V1040 is stationary, the Encoder and the V130 are on the lift. The connection is via a dangled cable and is connected in the same sequence. 120 Ohms resistors are installed at the V1040 & the V130.

2. If CAN Open is used by itself, then there are no issues ( the distance is not a factor), similarly, using only Unican again has no issues. The problem arises when both are used.

3. My work around has been to use the Encoder and V130 on CANOpen and communication between V1040 & V130 is being done on RS485 (MODBUS). I am using the very same dangled cable and am having absolutely no issues with this combination.

 

However since Unitronics has an option of using both CANOpen & Unican, I think, its appropriate that an example of this is included.

 

Regards

 

Lawry

[Ausman]

Hi Lawry,

 

1).  You have the resistors, but is the software termination set correctly at the encoder?

 

2).  So either Can on it's own generates no counts on their error bit at all?  But if you run both Cans, does the error rate rise dramatically on each or one?  Maybe indicating some sort of buffer problem which might be simply fixed by timings changes?  Again, I'd also be trying to log where the lift is at the time of failure.

 

3).  I personally would be putting the encoder as fixed, not on the lift, to make things a bit easier.  It must have a hell of a rewind spring to hold up 50m of joining line!  Or have I got that wrong?  To me that's fundamentally wrong locations for the various operations, but I don't know the install's quirks.  It sounds like the 130 is telling the system the location of the lift, but this indication is then via the flexible link.  I'd have the 130 purely as a "remote control" giving instructions to the 1040 and nothing more.  The 1040 does all the work which would likely let you get around issues a lot easier.  And I have a little bit of a problem with the encoder being bus based anyway.  If the potential is there to drop packets that indicate where something that moves is, I see this as a problem.  It might be impractical for your situation, but I have used laser distance encoders with success in some of my stuff where lineal counts weren't accurate enough.  Not good for a dirty place, though.  My final positioning is done by other shorter range sensors.  The distance stuff is for "transition b/n endpoints control" speed control.  Although in theory counters never lose track of where they are, in the real world I see it enough to implement other controls to double check this or handle things appropriately.

 

Cheers,

Aus

[lawry]

Hi Ausman,

 

In the earlier trials (when i was using both Canopen & Unican), the termination resistors were on the V1040 & the V130. These 2 being the ends & the encoder in the middle as far as the daisy chain went.

 

Now the termination is set on the V130 & the encoder. And YES the termination is set correctly.

 

Apart from relaying the lift position and various sensor statuses to the V1040, the V130 has only one other function, that of operating a latch via a single solenoid ( the power supply for this output is different)

 

The communication has been established by means of a trailing cable of fixed length. This cable moves freely along with the lift.

 

Thanks

 

Lawry

[Ausman]

Hi again Lawry,

 

just to clear what might be confusion, the encoder I quickly found matching numbers for was a draw wire one, that was why I commented on the 50m of line as being unusual and perhaps the encoder being better located on the ground.  And also the laser comments etc. 

 

But I must have found a wrong reference as with further digging it looks like you're deriving a count from a mechanical rotation means on the lift. That might clear up some of your head scratching on my comments!

 

I'd still be logging things as a first step along the solve path.

 

Cheers,

Aus