Overflow detection in TIA Portal (S7-1500)

I have one weird drive, which has 65536 pulses/revolution, which go from -32768 to 32767, value I'm receiving from it goes within that range (over Profibus).
I need to keep track of absolute motor position, since it's driving a hoist up-down, easy way is to count turns of a motor and add current value from encoder (which would represent angle from referent position).

Idea would be to detect overflow of a integer variable, and add and subtract turns (depending if motor rotating CW or CCW) depending on how overflow happens, from 32768 to -32767 or from -32767 to 32768.
Is there some system variable I could use for that? It would make it more elegant and simple.

I am curious about the INT value you receive from the drive.
The counter cards I know of returns DINT (in S7-1500 maybe even LINT).
With DINT you can more easily keep track of the absolute position since it doesnt overflow each turn.
If the drive does the encoder evaluation for you, isnt there a return value from the drive with the absolute position ? Or maybe separate no of complete turns plus partial turn ?

JesperMP said:

I am curious about the INT value you receive from the drive.
The counter cards I know of returns DINT (in S7-1500 maybe even LINT).
With DINT you can more easily keep track of the absolute position since it doesnt overflow each turn.
If the drive does the encoder evaluation for you, isnt there a return value from the drive with the absolute position ? Or maybe separate no of complete turns plus partial turn ?

Click to expand...

I know, it doesn't make much sense to me. But from specification I got from manufacturer it says it's integer and withing range I wrote. That's why I say it's strange drive.
We asked for number of turns from manufacturer but reply we received says there's no such thing as parameter which could be sent over Profibus.
Also that encoder value is absolute position according to manufacturer, but within one revolution. I presume this means shaft position is always related with one number from that range and it's fixed, we can't assign one position as referent position (as 0).

Another problem I think we'll have is that I'm not sure if 1500 is fast enough to do scan cycle faster than one turn at rated speed of 1500 rev./min. That is 25 rev./sec. or one every 4ms. Scan cycle of this 1500 will be probably higher than that, since it's supposed to do a lot of things beside hoist lowering/lifting.
This means sampling will be ****ed up. Currently I think we need to do this with cyclical interrupts of 1-2ms. Another problem is that all drives in this project are like from this manufacturer.Which means a lot of interrupts, which will **** up OB1 execution.

I have to check at what speed motor will run, but from gear ratio I think that it's gonna be nominal speed.

My bad, it's 40ms for one revolution. This is above one scan cycle time and there should be no problems with this then.
One good news from today.

Hmm, 40ms scan cycle for this PLC might be problematic, without test in real conditions we can't know. That's what older colleagues told me.
We use 1517 PLCs in this poject, which are slower than 1518, for 1518s I hear they're extremely fast.
Problem with this PLC it has Profinet communication with other PLCs, and Profibus communication with dozens of drives like this.
Who knows what scan cycle time is without test in real conditions?

Using a cyclic interruption

Hi doomsword,

You may use a cyclic interruption every 5 or 10 ms. The S7-1500 firmware will take carre and execute the code in the interruption exactly every 5ms. This is not a problem even with a humble S7-1200.

Best regards,
Kelkoon

Kelkoon said:

Hi doomsword,

You may use a cyclic interruption every 5 or 10 ms. The S7-1500 firmware will take carre and execute the code in the interruption exactly every 5ms. This is not a problem even with a humble S7-1200.

Best regards,
Kelkoon

Click to expand...

I'm thinking about, but we have many drives on this PLC. Interrupts could **** up OB1 execution imo.
Maybe we do calculation of current position for every drive that needs it every 10ms, but that would be a lot of code in one interrupt.

You should worry about the Profibus Target Token Rotation time (TTR).
If you say the S7-1500 has to receive the cyclic information from the drive, and the update should read at least twice per revolution (my opinion), then your TTR should be max 20 ms or maybe 15 ms to be sure. Notice that it is not TTRtyp (which is usually significantly smaller than TTR), because that one is not the guaranteed value.
It becomes complicated since you have to keep track and account for when the position rolls over the INT range.

I would let the drive be a simple drive that just runs the motor at the speed given by the PLC, and then connect the encoder to a dedicated counter card in the S7-1500. And you can handle the home position yourself etc. etc.

Just to tell, we have 41 of these drives on Profibus for this PLC. I don't know much about Profibus network management, but I feel this could last more than 40ms for entire token rotation between nodes.
Good side is I think not every drive needs position control, but with so many drives and people on this project I can't exactly tell. We try to make standardized FB which would manage entire possible interface between our PLC and these drives.