I'm relatively new to Labview Real Time modoule and want to implement one Controller(not PID one) in Deterministic Loop! I have already designed discrete Transfer Function and searching for the way to build one Controller with it! Is it right to use the Simulation Loop instead of Timed Loop (in this case Deterministic loop) and implement the controller in it?! If it's correct so, should I use the same clock and Priod as Timed Loop?!
It would be very helpful, if there is an Example about using transfer function in Real Time Loops!
thanks for your help,
to be honest: So far I haven't quite understood, what you're trying to do. Could you please be more specific.
You mentioned, that you implement ONE controller. Does this mean you have more than one controller?
Could you please be more specific on what you are trying to do? Maybe give us some sample code?
I have the same issue, that is, I want to implement a control algorithm that doesn't fit within the structure of a PID using a timed-loop. I am using the discrete transfer function VI to implement the control algorithm, however, I am not sure about the sampling time I should use in calculating the dicrete transfer function of the controller. Should the sampling time be equal to the sampling period for DAQmx? Can it be higher/lower? I am calculating the discrete transfer function of the controller from the continouous time transfer function which is obtained through simulations.
Also, I am not 100% sure whether I have correctly used the shift-registers for closing my feedback loop.
Attached is the VI with the discrete transfer function inside the timed-loop.
Any idea would be greatly appreciated.
Hello both of you,
If you have a discrete transfer function (written in z-1) at a specific sample time, then the easiest way to realise in a real-time LV application is using a timed loop with either shift registers or feedback nodes for the z-1, z-2, etc terms. Basically you have to rearrange your discrete transfer function into a difference equation so that you have the output (y(k)) written in terms of the current input (u(k)), previous inputs (u(k-1), ...) and previous outputs (y(k-1), ...).
The discrete time transfer function is only valid at the sample time (Ts) you determined it at - if you change the sample time the co-effcicients of the transfer function change. If possible, it is better to write the transfer function as a function of Ts, so you can change Ts and not have to recalculate the transfer function.
The timed loop must run at Ts (but in milliseconds), and this must also match the sample time of the signals you have going into or out of the transfer function. If you have mismatch, it might look like it works, but you might be injecting a lot of jitter on the signals.
Thanks for the reply. You mentioned one way to realize a discrete transfer function in real-time LV is to rearrange the transfer function into a difference equation. Does that mean that we should eliminate using the discrete transfer function VI and instead use difference equations?
In my case, I have obtained a continuous-time transfer function for the control algorithm from simulations. I can easily convert the continuous transfer function into discrete transfer function in MATLAB or LabVIEW with a sample time of 1/4000 sec (my sampling freq. is 4000 Hz for signal acquiring, generating, and loop rate), and "first-order-hold" method, as I found this method provides almost identical discrete transfer function to the continuous one over the frequency band of [0-1000] Hz for my application.
I am also using the shift-register as suggested by you in the VI I attached in my previous post. Based on our discussion, could you please check my VI to see whether I am doing things right here?
Also, if the sample frequency of the discrete transfer function in the timed-loop is at multiple integers of the sampling rate (e.g. 12000 Hz for tranfer function and 4000 Hz for sampling rate, 12000=3*4000), would it somehow improve the resolution of the controller command?
Thanks very much for your consultation.
Sorry I can't open your VI (looks like it is a new version of LV than I have installed).
You're right - you don't need to convert to a difference equation if you have the CD&SIM Module which can take discrete time transfer functions directly. You don't need shift registers with this function, as it is effectively done internally. If you don't have CD&SIM discrete TF's can be implemented easily just in a timed (or while) loop with feedback nodes or shift registers to replicate each z-1 you need.
Some more ideas:
"if the sample frequency of the discrete transfer function in the timed-loop is at multiple integers of the sampling rate (e.g. 12000 Hz for tranfer function and 4000 Hz for sampling rate, 12000=3*4000), would it somehow improve the resolution of the controller command?"
This could actually make things worse - but depends on your transfer function if it is a problem. Think about it this way - in the scenario you state the input signal going into the Discrete TF will only change once in every three samples, that means if your transfer function includes a 1-z^(-1) factor (i.e. a derivative) - that will be zero for two samples then jump up for the next sample. You'll observe a very jittery/noisy signal, but the noise is due to samples not being correct. This will also occur if the sample times are very similar but go in and out of sync where you may get the occassional sample that is the same and hence the occassional zero in the TF.
In an application I had we had problems trying to get the data coming into a timed loop and the timed loop itself synchronise, and before it was fixed the control signal was very jittery.
How would you implement a negative feedback with the CD & SIM Module? It doesn't seem to have such functionality.
Yes it does.
Control and Simulation | Control Design | Model Interconnection | CD Feeback.VI
Plenty of info in Help file to take you from there ....
Well it doesn't seem compatible with the "Discrete Transfer Function" and other stuff available on the CD & SIM Module.
I used the Gain functionality in a reverse scenario as attached. Not sure if this accurately does what I intend it to do even though initial testing seems to show it's somewhat working. Please take a look at my VI. The control block diagram is also attached in the pdf format.