Help: PLC Ramping Continuous vs Discrete

[NewEngineer]

That depends...

traditionally, most PLCs only update the I/O at the beginning/end of the main program cycle. At the beginning of a cycle the actual inputs are read into a input process image. The main program executes using the process image inputs and sets any out puts in the output process image. At the end of the main program scan the ouput process image is transferred to the actual outputs.

Some PLCs update I/O acyclically from the main program cycle (Rockwell I think?) and this can catch people out. In some PLC languages, for example Siemens PLCs, you can read and write directly to the I/O and this is often used in timed interrupt routines. Read direct from Inputs, execute interrupt code, write directly to outputs.

So, the short answer is: it deponds on what PLC you use and how you write the program.

Nick

After reading the manual the PLC reads the inputs at the start of the Main Task Cycle Time and updates the outputs at the end. It does not update the I/O acylically. I think this means having a faster timed interrupt would not help as the outputs are only updated at the end of the Main Task Cycle.

 

[JesperMP]

I haven't tried this in TIA portal, but do the PIW/PQW "shortcuts" work there as well?

It is the same but different.
The equivalent to "Pxxxx" is to write "%xxxx".

But, since the data is transferred via Modbus TCP, the transfer rate will be quite a bit slower, also slower than the main CPU cycle.
edit: And has nothing to do with IO access, with direct peripherial access or not.

 

[drbitboy]

5minutes (100kW @ 20kW/min ramp) is 600s. 0.1% of 600s is 0.6s.

Five Modbus TCP messages every 3s is easily achievable (even with Modbus RTU), and any device that is degraded or damaged by 0.1% steps should be replaced.

 

[JesperMP]

5minutes (100kW @ 20kW/min ramp) is 600s.

That must be 'imperial' minutes (ha ha).
In my world 5 minutes is 300 seconds.

 

[NewEngineer]

I would not program an 'increment per cycle'. This will sum up a small error at each cycle, which will be greater the smaller the increment and can be quite significant after 5 minutes.

Instead I would use a timer for the duration of the 5 minutes for the change, and calculate the fraction of the full setpoint based on the fraction of the time expired. You will then get precisely 100 % of the setpoint when the timer reaches 5 minutes.

This is a nice approach. I think this relieves the implementation of interrupts. I could run the ramp program with timer in the normal program cycle (Setpoint:= TimeElapsed(sec)/300sec * Setpoint). PLC will send this setpoint to the inverter at the end of every PLC scan.

What is the data format of the variable that is sent to the VFD ?
INT, DINT, REAL, .. ?
If it is an INT, then the max value is 32767, and you will only see a change in the value approximately every 9 mseconds. 300000 ms / 32767 = 9.15 ms. (*)
I think that you dont have to worry about achieving a smoother transition of the setpoint value than what you can achieve with the regular PLC cycle. Even if the variable is a DINT or REAL, in the real world I dont think it is worth trying to get a smoother transition. Every 10 ms is still much smoother than every 1 second, by a factor 100.

*: This assumes that the value is scaled to 100% = 32767. If 100% is less than 32767, for example 10000 = 100.0 %, then the change in the value will be even less frequent.
*: Or 10000 = 100.00 kW

The value that is sent to the inverter is an INT of range 0-1000 (scale 0.1). It's a power% of the nominal power of the inverter (100kW) that is sent to the inverter. eg., if 500 was sent then the inverter will "see" the setpoint as 50kW.

I'm not quite grasp the 9.15ms. Is that the time interval for sending the setpoints to the inverter?
Please correct me, my assumption was the setpoint is sent to the inverter every scan cycle?

Thanks for your help!

 

[L D[AR2P#0.0]]

On a side note, what are you controlling that needs a power setpoint?

 

[JesperMP]

*sigh*

PLC will send this setpoint to the inverter at the end of every PLC scan.

If the connection between the PLC and the VFD is Modbus TCP as you write, then the update between the PLC and the VFD will not be every scan of the PLC program.

The value that is sent to the inverter is an INT of range 0-1000 (scale 0.1). It's a power% of the nominal power of the inverter (100kW) that is sent to the inverter. eg., if 500 was sent then the inverter will "see" the setpoint as 50kW.

That means you cannot get a smoother transition than 0.1 kW.
In your 1st post you have a step change of approx 0.33 kW. So it will only be slightly better to achieve 0.1kW.

I'm not quite grasp the 9.15ms. Is that the time interval for sending the setpoints to the inverter?

That is based on that if you use the range of the INT from 0 to 32767, then within 5 minutes, there will be an increment every 9 msec (300000 msec/32767 increments).
But since you use 0 to 1000, then there will be an increment every 300000 msec/1000 increments = 300 msec per increment.

I am guessing that you are updating the Modbus TCP blocks every second, that is why you see the 0.33 kW increments.
To achieve a transfer rate of approx 3 Modbus TCP telegrams per second is possible, and thus you get to the 0.1 kW increments.
I would observe the 'done' bit of the Modbus TCP blocks to have them update as fast as possible, and then use the calculation based on the expired time.

 

[drbitboy]

That must be 'imperial' minutes (ha ha).

In my world 5 minutes is 300 seconds.

doh!

well, as you note, that would be a message every 300ms or 0.3s, which is also unlikely to be anywhere close the limit of what Modbus TCP can do.

I would set up two asynchronous sets (threads) of logic in the PLC:

1. A 0-1000 counter that increments on every rising edge of the DONE bit of the Modbus message instruction (assuming there is one).
2. A 300ms repeating timer;
   1. on every timer DONE bit (a one-shot),
      1. if the Modbus message DONE bit is also 1, then start a new Modbus message with the current counter value
      2. otherwise do nothing (miss a cycle; who cares?)

Initiation and termination will be awkward:

• There is no message DONE bit to send the first message.
• The counter.DONE (.Q?) bit will be 1 before the final message, with a value of 1000, needs to be sent.

It will also have to handle message error conditions, but that basic structure should work.


We still don't know what PLC is being used.

 

[Steve Bailey]

If the command signal from the PLC to the VFD was an analog output, I might do the ramping in the PLC, but with the signal coming over a network, I would opt for using the drive's ability to ramp a step change in command signal.

 

[cardosocea]

On a side note, what are you controlling that needs a power setpoint?

Could be a power limit, I assumed as such at least.

 

[Peter Nachtwey]

Why not use 10 ms interrupts. This way there are 500 increments of 0.2%.
I agree with the others that the power should be incremented due to rounding errors. I would set a variable I to 0 and increment it every interrupt. I would multiply I by the 100 percent value and then divide by 500 to get the value to output. Make sure you multiply THEN divide. This method doesn't have any timer problems nor will output be subject to the rounding error caused by incremental additions. Using floating point for the everything but I will be OK.