How to calculate direction via CANopen position data

[kratmel]

OPLC V1040 is used for control Lenze 8400 Highline servo drive.
Position of vertically moved linear axis is measured by servo drive encoder and translated to the panel via CANopen.
Drive use his own logic for continuous UP - DOWN move changeover.
Now only START and STOP command sended to the drive via CANopen.
AXIS is connected with 500kBps speed and moved with 0.8m/s max speed.

I need to build  programmed limit switch (PLS) for control machine valves depending of axis position.
It must be switched separately. PLS in UP and DOWN move is different.
Now i have 32bit absolute axis position copied to the ML.
Problems:
1) how to calculate the axis moving direction by data manipulation with ML;
2) how to STOP axis as much as posible close to the UP or DOWN end position using only ML data and sended via CANopen "stop" command.

Any ideas?

[Joe Tauser]

Unfortunately, the only thing I really know about CANopen is how to spell it, but I may be able to help a bit.

One of my favorite tricks for trying to make Vision act a little more realtime-ish in a motion application is to use the 1.25 ms interrupt routine and put what logic I can in there.

I tried configuring a V1040 with the necessary init blocks and the interrupt routine.   Then I tried dropping a CANopen SendPDO block into the interrupt and the compiler choked on it.  I'm guessing this is because the CAN port is like other ports and only serviced at the end of the scan.  Maybe a Creator can chime in on this.

For problem 1, you could store the last value of your ML in a buffer register every scan and compare the new ML value to it.  You can tell if it's going up or down by whether the new value is greater than or less than the buffer value.  Then copy the new value to the buffer.

I think you're probably limited on problem 2 by the scan time.

Joe T.

 

[Ausman]

Kratmel, I'm with Joe on it being a bit hard, and agree with his direction of travel method.  But I will throw in something I often have to do with the stuff I make.

I'm assuming that there is an inbuilt ramp time in the process.  Even if there isn't, my method is to write a program that triggers start and stop actions based on accurately done time intervals.  The motion is set to it's native start point. At time zero you send a start message, and then at the end of your first progressively increasing time period you send a stop.  The plc then records the absolute movement result in a table matched to the time period.  The physical motion is then reset to the native start point and the process begins again using a slightly higher time period.  Once you have done this for the entire time range you have dictated in your "learning program", you then do it backwards, with the start point being the uppermost native limit point.  If needed, the same thing can be done using a different native start point, in case the physical action is not direct but "leveraged", which might mean a different amount of time to travel a given distance if the start location is not the native end point.

Done correctly, this method lets you build a database that gives a good idea of how long a time is going to be needed between start and stop signals to travel a certain distance.  It is all done by the plc without any human involvement.  Trust me....doing this manually turns into a nightmare!!!  Having the subsequent database makes it very easy to adjust things to be very close to your aims.  Fine tuning can be done if needed by actual trial and error, which is made so much easier by your times being based on something that has been done in reality.  Often I don't need to adjust anything at all, it is spot on.

The problems with the method are that the travel speeds may change slightly over time, someone might fiddle with the drive's parameters or trim pots get "old and noisy",  different loads etc.  To this end you can redo the learning cycle periodically and see if there are any differences.  These differences can be automatically applied to the normal program if you want to do clever maths that adjusts MIs etc where relevant.

cheers, Aus

[kratmel]

Thanks for the good tips Joe,  Aus .

I did some testing on the above problem.
The main thing that I understood - in fact, I can not get a new coordinate faster than completing the read data from the servo.
I laid this principle as a basis and I managed to determine the direction of travel without interrupt.

Given that the direction is 1 bit, changing it to 1 or 0 is the extreme point of movement up or down, respectively.
This method gives a stop error for the time of the drive deceleration. However, it does not actually affect the process.

I tried to refuse automatic up-and-down motion control from the servo. However, PLC control over the network was unstable. Reaching a predetermined stopping point, the servo via the network announced that the target coordinate had been reached. After that  PLC send  command for the new movement.
This method gives a good result in stopping and managing the process.

However I couldn't figure out why but the normal  cyclic up-down movement controlled by PLC via CANopen didn't last long and must to be restarted again.
Now I'm trying to apply the Aus idea with a stop command ahead of time for an exact stop.

I will report on the results later

[kratmel]

Results...

This project is delayed by lockdown...

And now all problem with PLS (Programmed limit sw.)  is solved. Machine run without problem  for 24/7.

After some test i find the way to easly check UP and DN direction. And all 8  PLS is divided to 8UP PLS and 8 DN PLS and stored to recipie.

STOP in UP and DOWN is performed via Aus  idea - but the main problem is to get information about direction.

This is  some part of code used in my project. Main idea - use scan time for data manipulation.   

Position copy from CAN DW1 must be placed after Compare blocks.