Discrete Step Response Works With 'Bilinear' But Not With 'ZOH' #1238

I do not think this points to a zoh bug by itself. The important detail is that the code discretizes the open-loop transfer function Ls and then closes the loop in discrete time.

For the numbers in the example, that produces a discrete closed-loop pole well outside the unit circle with zoh. I get approximately:

zoh closed-loop poles:      -30.52, 0.9797, 0.4996
bilinear closed-loop poles:  -0.844, 0.9797, 0.4992

So the failed step_response is consistent with an unstable discrete-time closed loop. You can check this directly with something like:

process_fdbk = ct.feedback(ct.c2d(Ls, Ts=T, method="zoh"), 1)
print(ct.poles(process_fdbk))

Conceptually, zoh is modeling a zero-order hold at the input of a continuous-time system. It is not usually the right way to discretize a PID controller multiplied into the plant and then close the loop afterward. If the goal is a digital-control model, I would discretize the plant with zoh, discretize/design the controller separately, and then close the loop. If the goal is only the sampled equivalent of the already-closed continuous-time system, sample fdbk_Ls instead of Ls:

process_fdbk = ct.c2d(fdbk_Ls, Ts=T, method="zoh")

Those are different systems, which is why the zoh and bilinear results here should not be expected to behave the same.

@AMBRA7592,

thank you for your time for looking into this.

Point 1.
As you stated, because a particular pole is well beyond within the unit circle (equivalent to RHP in continuous time), the process is unstable. If this is the case, why not just plot the system with its unstable response as any other system that is unstable versus generating an exception?

Point 2.
So, from your response, one should perform the continuous to discrete time conversion only after closing the loop when performing a step response test? Is this the go to process?

Tbh, for me this is a little odd since it is ok to perform the open-loop (L(s)) continuous to discrete time conversion in the case when you want to perform the root locus test.

Again, appreciate your feedback and your time.

Thank you.

Following up with my previous response, I have a question regarding the following transfer function - see figure. The plant requires having a 'zoh' transfer function just prior to it - the compensator D(z) doesn't. If I was to design a compensator in the time domain, series it with the plant, then apply unity feedback, and then finally converting it to the discrete time domain, would that bypass applying the 'zoh' to only the plant versus to the entire closed loop transfer function?

Maybe I am not understanding. Can you please advise.

Here is the test script:

def root_locus_plot(plant):

    """
        Pass in the Open Loop L(s) Gain Transfer Function

        L(s) = G(s)*Gc(s)
    """

    plt.style.use('dark_background')
    ct.root_locus_plot(plant, color='red', grid=True )

    # Plot custom circles on both sides of the imaginary axis (e.g., constant w_n = 2 and w_n = 4)
    theta = np.linspace(0, 2 * np.pi, 100)

    r = 1

    x = r * np.cos(theta)
    y = r * np.sin(theta)
    plt.plot(x, y, 'c--')#, label=f'$\omega_n = {r}$') #---

    plt.show()

# 1. Test in the continuous time domain

# Plant
plant = ct.tf([0.6], [1, 0.02, 0])
root_locus_plot(plant) 

# Compensator - Zero cancels pole close to imag. axis
#                         and added pole at s = -4
K = 18
Gc = ct.tf([K, 0.02*K], [1, 4])
Ls = ct.series(plant, Gc)

# Close the loop
Ls = ct.series(plant, Gc)
Ls_fdbk = ct.feedback(Ls, 1)

# Get step response
plt.style.use('dark_background')
response = ct.step_response(Ls_fdbk, np.linspace(0, 7.0, 500), return_x=True)
response.plot(plot_inputs='overlay', title='System Step Response')

# Plot compensator + plant in closed loop
plt.grid(True)
plt.xlim(-0.01, xmax=7)
plt.ylim(-0.05, ymax=1.2)
plt.show()

@AMBRA7592,

thank you very much for your detailed response. This really cleared things up for me. Especially point 2. This now makes total sense for me. I liked that you explicitly created the Dz compensator using the 'bilinear' method. I was under the impression (incorrectly of course), that I could implement the compensator using the same 'zoh' method as the plant (for 'consistency'). This perked my curiousity and so I googled if they required having the same method. This is the response that was provided:

No, they do not need to use the same discretization method. In fact, standard digital control theory generally dictates using different methods because the plant and the compensator serve entirely different roles in a sampled-data system.

The Plant: Should be discretized using a Zero-Order Hold (ZOH) equivalent. This is because real-world physical actuators (like DACs or motor drives) hold signals constant between sampling intervals, making ZOH the theoretically perfect representation of the system.

The Compensator: Is a mathematical algorithm running on a digital processor (e.g., FPGA, PLC, or microcontroller). Discretizing it with ZOH would mathematically double-count the hold effect, resulting in incorrect phase characteristics. Instead, approximations that don't add hold logic—like the Bilinear (Tustin) transformation or Pole-Zero matching - are preferred.

You have definitely helped me more than you can imagine. Wow!

As always, I am very grateful for your kindness with your time.

Thank you very much sir. May you be repayed ten fold.

👌💯🙂

Following up with the discretization discussed in your last response. The explanation makes total sense and I believe as per theory, that this should work.

However, I am a little baffled as to why, when passing in the closed loop discretized transfer function, it does not plot as expected but if I perform the discretization to the continuous time domain closed loop, it does.

Here is the test script in its totality where both continuous and discretized are provided (thought the discretized is not plotted as expected when following the steps as highlighted in the last post - you will have to comment/uncomment one version to test the other):

# Plant
plant = ct.tf([0.6], [1, 0.02, 0])

# Compensator - Zero cancels pole close to imag. axis
#                         and added pole at s = -4
K = 18
Gc = ct.tf([K, 0.02*K], [1, 4])
Ls = ct.series(plant, Gc)

# Close the loop
Ls = ct.series(plant, Gc)
Ls_fdbk = ct.feedback(Ls, 1)

# Get step response
plt.style.use('dark_background')
response = ct.step_response(Ls_fdbk, np.linspace(0, 7.0, 500), return_x=True)
response.plot(plot_inputs='overlay', title='System Step Response')

# Plot compensator + plant in closed loop
plt.grid(True)
plt.xlim(-0.01, xmax=7)
plt.ylim(-0.05, ymax=1.2)
plt.show()

# 2. Discrete time domain

T = 1 # sampling time = 1s

# Disretize individual blocks per previous post  <---------------
##Gz = ct.c2d(plant, Ts=T, method='zoh')
##Dz = ct.c2d(Gc, Ts=T, method='bilinear')
##Lz = ct.series(Dz, Gz)
##Lz_closed_loop = ct.feedback(Lz, 1)

# Discretize closed loop          <---------------
Ls_fdbk = ct.feedback(Ls, 1)
Lz_closed_loop = ct.c2d(Ls_fdbk, Ts=T, method='zoh')

# Perform step response test
resp = ct.step_response(Lz_closed_loop)

# Plot using a discrete stem plot
plt.style.use('dark_background')
plt.figure()
plt.stem(resp.time, resp.outputs)
plt.title("Discrete-Time Step Response (dt=True)")
plt.xlabel(f"Sample Index (k), Ts = {1} s")
plt.ylabel("Amplitude")
plt.xlim(-0.03, 25.0)
plt.ylim(-0.05, ymax=5.2)
plt.grid(True)
plt.show()

Update:
Ok, I found the issue. I was following the sampling period of 1 s as per the stated problem in the book (reference a previous post where I posted both the block diagram and the stated problem DP13.6). If I decrease the sampling period to say below 0.2 s, then it starts to work as expected - somewhat - still a bit high overshoot, however. If I bring it down further to 10 ms, then it closely resemble the continuous time domain version. Perhaps the book provided the wrong or unrealistic sampling period for the stated problem inadvertantly (?). Though still odd that with the other method it works with 1 second as the sampling period. ❓❓

Well, I am glad resolved this. Hope it helps anyone else that is perhaps having a similar issue. 🙂