TIA Portal - Get current data and continuously move to a register for shutdown use

[bgtorque]

Here's an interesting one. I have an S7-300 and am using TIA Portal V13. I have a pressure/flow (p/Q) control valve for oil pressure for controlling oil with feeds a thrust pad bearing, with respect to the thrust generated by the speed of the driveline. The oil supply has an accumulator that should be good for around 2mins supply and the PLC and control valve are all UPS controlled. So, should power be lost or the oil pump/drive fails the accumulator will ensure the oil supply for (hopefully) enough time to keep the thrust under control to bring the driveline down to a stop.

I am monitoring the driveline speed, the thrust/oil pressure/oil flow. I would like to continuously capture the characteristics of the speed vs. pressure/thrust relationship during normal running, so that I can use this data to command the correct pressure in the pad as the speed reduces.

i.e as the driveline increases in speed from rest up to say 2000rpm I might have (i'll use coarse steps)

0rpm 0kN
500rpm 1kN
1000rpm 3kN
1500rpm 7kN
2000rpm 12kN


So if I lose pump power at 2000rpm then teh driveline will start to coast down and I want to ensure that I am controlling thrust at 12kN initially and tehn as we transition down in speed it hits 1500rpm so I then control to 7kN, and so on.

Ideally I would like much finer steps, 100'rpm or even 10's rpm but am practical in the amount of data would need to be stored, so would find a sensible limit.

What would be the best practice in achieving this in terms of ladder code (ideally ladder as that's want I have most experience of). I'm guessing dumping the data to an array of x vs. y in some way? I could write something simply if it was just for a few points like I have described above as it would be a line of code for each. But lets say my speed is upto 20 000rpm then this would be a lot of MOV instructions and IF or == statements. There must be an elegant way of coding this simply that eludes my knowledge?

Any help would be appreciated.

Thanks,

 

[RVaughan]

Is there a reason you want to reduce it in steps? First thought is to develop a formula for the deceleration curve and use that. Pressure required is x, speed is y, flow ought to be z...

Not sure if I'm expressing this right, but you should be able to create a formula and then use the floating-point math instructions to get a smooth, correlated pressure reduction. Use of Peripheral I/O and cyclical interrupt blocks will give you as close to instant feedback as you can get.

 

[bgtorque]

Thank RVaughan. I am only looking at steps as otherwise it might be an awful lot of retained data if it was at 1rpm resolution? I'm not knowledgeable enough to know if that is feasible and whether the CPU has the memory/processor power to do that on the fly with everything else?

Bear in mind, I dont know ahead of time what the speed vs. flow/pressure relationship really is. Ultimately the customer will define that depending on the unit they are testing. Hence me wanting to retain and use the real relationship data on the way up to whatever their max. speed for that particular unit is.

I'm not sure what you are are getting at with the peripheral I/O and cyclic interrupt blocks either. Could you point me to an example of some sort?

Thanks again and I appreciate your comments.

Cheers

 

[DeKemp]

I'm not sure what you are are getting at with the peripheral I/O and cyclic interrupt blocks either. Could you point me to an example of some sort?
Cheers

Siemens has OB30-38 which are cyclic, meaning that for example OB35 which has a default of 100ms. Will be called every 100ms, it will interrupt OB1 execute OB100 when it finishes with OB100 it will return where OB1 left off.

With peripheral i/o (PI,PIW,PQ,PQW) you can directly read/write without accessing the process image, which only is read at the start of the cycle and written at the end of the program.

(can someone confirm the process image part?)

 

[RVaughan]

With a formula you wouldn't need to retain the data, as the processor is more than capable of doing the math on the fly. If you want 1 rpm resolution that's really the only way to go. Whether you could retain all that data in a lookup table depends on the size of the rest of your program and which S7-300 model you have.

Someone who remembers their high school math better than I could show you how to develop a formula based on some setpoints you input, so you could use the same block of code for different test units.

Peripheral I/O are regular I/O read or written to immediately instead of waiting for the regular update part of the scan cycle. They are addressed, for example, as PQB44 - peripheral output byte 44. Here's an online manual that explains it: https://support.industry.siemens.com/cs/mdm/109011420?c=73472868363&t=1&s=peripheral&lc=en-AT
[If that link doesn't open directly to it, open the "Direct access to the I/O (PI and PQ memory areas)" section]

Cyclic interrupt blocks are called on regular time intervals and interrupt the PLC scan so they always run on that interval. You can call an OB that contains your valve control logic every, say, 100ms, and use the peripheral I/O to read your speed and flow immediately, make a calculation, and send a new position to your valve immediately. Here's another manual link: https://support.industry.siemens.com/cs/mdm/109011420?c=73475119499&t=1&s=cyclic interrupt&lc=en-AT
(Section is titled "Cyclic interrupt OBs")

 

[Pete.S.]

Sorry to say but ladder is unsuitable for data manipulation and calculations. I suggest using SCL.

It's no good using a formula unless you know exactly what it looks like and I guess you don't.

What you could do is create an array of suitable size, say 101 floating point values (0 to 100) representing thrust at speeds from 0% up to 100%.

Every scan you check the thrust and put it in the right place in the array for that particular speed. To make this an accurate value you should do filtering as well. This means that the array will contain the average thrust at that particular speed.

Easiest way is to do filtering is something like this (speed=54%):
arr[54] := (thrust-arr[54]) * 0.05 + arr[54];

(arr is the name of the array). If you want more filtering decrease 0.05.

When you need to output the thrust you just check the rpm and convert it to speed % and use that to fetch the thrust.

I doubt you would need better precision. But if you do you would still use the values in the array and interpolate between them.

Let's say speed is 54.5%. The thrust at 54% is 8.32 kN and the thrust at 55% is 8.79 kN. The thrust at 54.5% is right in the middle so 8.555 kN.

An example of interpolation of a curve. Linear interpolation to be exact.

 

[bgtorque]

Thanks for the comments. Certainly giving me food for thought.

I was thinking of doing something simple as follows. The problem being that there are a lot of lines of code. I could make my steps nice and coarse as I mentioned earlier, maybe every 500rpm?

speed>0-----speed<=100---------MOV Thrust to Thrust_data[0]
speed>100-----speed<=200---------MOV Thrust to Thrust_data[1]
speed>200-----speed<=300---------MOV Thrust to Thrust_data[2]
speed>300-----speed<=400---------MOV Thrust to Thrust_data[3]
and so on