Encoder help

[Circiter]

Hi,

I have a S7-1200 (214-1HG40-0XB0) connected to a SEW Movitrac MCX91A-CFN V4.0 through profinet.

Now I have a EZ2Z Singleturn encoder on my motor that I have to determine my position with through an HMI.

It is like that , that I can move my motor 1mm at a time (or hold the button to move them quicker) and that I've must be able to save my position and start my program from there on. When my program runs the encoder has to move every step 1mm in.


does anyone have an idea on how to program this?

 

[parky]

Not exactly sure what you want to do but if I understand your post it sounds like before running the process the operator inches the position to a start position for automatic control, this becomes the start point when in auto control.
The way I would do it is on a setup page on the HMI, the operator moves the drive to the required start position, then press a button that stores that position to be used in automatic. be sure that the stored position is a retentive memory so that in an event of power down or recovery it will stil have the required stored position. a little difficult with a incremental encoder but perhaps on a power down or error, make the operator go back through a setup routine, also you must have perhaps a zero position sensor so that any error on movement on power down the system can be re-zeroed before a new teach cycle.
This is something I once did, every so many cycles or if the drive reached the max limit sensors it required a new calibration i.e. send it back to 0 (home sensor, reset the encoder count & then require a teach cycle.

 

[Circiter]

Hi,

Thanks, that's exactly the way it needs to be, How can I store the position before automatic? Is it in a DB?

 

[parky]

Yes, a DB is the best, just ensure it is retentive i.e. so thst on power down it holds the value when you power back up.
I did something similar, these used straitforward VSD drives not Servo's, did not have to zero though as there was a start point sensor that always kept it at the correct 0 point & reset the counter should it drift, it was the end point depending on the size of packs it was transporting, basically, on a teach cycle, the transport was moved by a teach button i.e. inch button until the packs were under the sealing head position, a button was pressed & it stored the position, this was then stored in a recipe for that size of packs for later retrieval. so in essence the same as what you are doing.

 

[Circiter]

Thanks for the help.

So far everything works (Position, Position readout,..)

Only one issue that I have, my encoder "jumps".

let us say I have a readout for 150mm, and when i select to move 1mm, my encoder suddenly jumps to 155mm?

Any ideas what's going on?

I checked my DB's and everything looks fine, even my math blocks?

 

[parky]

Is the actual transport moving from 150mm to 151mm or is it actually moving to 155mm if so then it's not your maths but the drive actually moving beyond the extra 1mm.
If that is not the case then it could be one of a number of things,
Either there is some "slap" (by which I mean worn gearing) between the drive mechanism or encoder.
The PLC is not seeing all the pulses, is this encoder in some interrupt or counter card ?
Your code is somehow not relating the actual position of the encoder.
An idea of how you are processing the encoder pulses would be useful, normally using a counter card specifically made for high speed counting may have some settings i.e. input response time, the same goes for using high speed pulses in normal Inputs for example: in Mitsubishi, the first 7 inputs of the brick PLC's like the FX range can be used as high speed inputs, when used in this mode the input response time is a few microseconds, however, when used in normal mode the response time is 10ms plus the scan time of the PLC due to the I/O update being syncronous with the PLC code scan time.

 

[Circiter]

Hi,

it is actually moving 1mm.

it isn't with a pulse counter or anything, the communication encoder - PLC happens through profinet by the movitrac controller.

I guess is made a mathematic fault somewhere?

 

[drbitboy]

could there be some schmutz on the encoder?