IRT program with siemens 1515cpu

[Shellmer]

First of all, it's a pleasure to join this community, I already have a few years of exp in this sector but never registered on a plc forum, so thanks in advance for any help or advice provided.

Well, getting in the matter, right now I am working on a project where I need to do measurements in real time, or at least, get readings the fastest way I can achieve.

I am working with 4 servos that are working in Isochronous mode + a fast analog card also with enabled isochronous mode and a 1515F-2 PN cpu.

I know a bit about real time aplications and I am aware of the limitations of code length and optimization needed in order to achieve faster cycle times, but as I have 4 servos, the technological functions are all linked to OB91 (MC-Servo), with runs in isochronous mode at a 6ms rate, analog card is also read within the same rate assigning the same PIP as the OB91 and called from the OB61 (synchronous cycle)

My problem arises when I want to reduce even further this cycle time, as I need to get to 1/2ms if possible.

Normal cycle time scan from OB1 is at 40ms since most processing power is dedicated to the RT measurements, this is not a problem and can be extended more if needed since the only important part is to take the measurements correctly. Problem is that I cannot split the OB91 work to only read and execute functions from one servo and run another instance at a different rate to control the other servos in order to reduce the overall load.

This makes the cpu manage all servos at the same time using the OB91 and if I try to reduce the scan rate below 5ms (both on ob91 and ob61 because they need the same rate in irder to read simultaneously) then I get syncronous communication errors and servos go to error.

Do I need a more powerful cpu? I really only need to read an analog signal + one encoder position from one servo... since I enabled isochronous operation things started to work pretty well but I needed to improve it a little more.

I tried to reduce the percentage of reserved cpu for communication processes but I achieved nothing, code executed on OB61 is already optimized and minimal, but it seems the servo block that is protected with know how is slowing all down. Next step would be to replace the cpu for a more powerful one but I want to avoid that step since delivering times are very hight right now.

I know much people may not have experience with real time applications, but any advice would be very appreciated.

 

[baref00t25]

You will likely need a faster CPU, also using a Technology CPU will help you as well (1517T); but that may still not get to the 1/2 ms cycle time. You best option might be the 1504D TF or 1507D TF drive controller. Any code that you need to run at the servo rate should be placed in MC-PreServo or MC-PostServo.

 

[mk42]

A technology CPU won't innately run your motion code faster, so a 1515T won't help you over a regular 1515, but going to a faster processor like a 1517 definitely would make a difference. The 1500 CPUs are somewhat exponential in the speed improvements as you go up the chain.


The other option is to get a 2nd CPU to offload the one high speed axis. This is the "official" solution to the "all motion TOs need to update at the same rate" limitation.

 

[Shellmer]

You will likely need a faster CPU, also using a Technology CPU will help you as well (1517T); but that may still not get to the 1/2 ms cycle time. You best option might be the 1504D TF or 1507D TF drive controller. Any code that you need to run at the servo rate should be placed in MC-PreServo or MC-PostServo.

That is exactly what I'm doing right now, at first I was using both OBs with the same configured rate and same PIP, but since the values I need to read are syncronized with the servo encoder I just called my measuring routine in the MC-PostServo, it makes things a little easier so I do not need to change the rate on both OBs.

That worked pretty well, but for some reason, even as it was working at 5ms rate just fine, right now servos are just giving fault "synchronous clock end-of-life" randomly.

I've activated the webserver and I've been monitoring the communication load, for some reason, it starts to spike and reach 50% usage even when servos are in fault state and not moving at all.

So next step I am doing is isolating the IRT network on the X1 interface and using the X2 interface to comunicate with all non IRT devices, hope this helps... if not, following step would be to get a faster CPU, but that will be more difficult as the delivery times are pretty high... if I can make it work with syncrhonized readings every 5ms I think it will be ennough, at least for the time until a more powerful CPU arrives.

Thanks for your help!

 

[Shellmer]

A technology CPU won't innately run your motion code faster, so a 1515T won't help you over a regular 1515, but going to a faster processor like a 1517 definitely would make a difference. The 1500 CPUs are somewhat exponential in the speed improvements as you go up the chain.


The other option is to get a 2nd CPU to offload the one high speed axis. This is the "official" solution to the "all motion TOs need to update at the same rate" limitation.

Yeah, I've been searching this info yeaterday, and technological CPUs I think would not give me much benefits over the normal ones, but it's true that processing power scales a lot on the next CPUs, so this may be the sollution.

Getting a secondary CPU to manage the readings + that servo would be a solution, I've seen this done on other cells that also need to gather data very fast, problem is that delivery times are very high here, I may be able to get another 1515 CPU but this will imply wasting much more time interfacing both cpus toguether.
I'ts funny to think it as an "official" sollution, but you are completelly right, I've tough the same but I am still trying to get it working using only one cpu if I can as the machine will be easier to debug and maintain.

This type of development remembers me when I programmed microcontrollers and I had very low ressources and I wanted to run something pretty fast... the only way was to get a more powerful microcontroller or to optimize code, even writting it in assembler.... fun times.