Unresponsiveness while using PWM and datalogging

[JammyHam]

Hi LabVIEW community,

I have recently run into difficulties while attempting to run a software-based PWM VI I created. Specifically, I am trying to log measured data while running the PWM algorithm. The main issue I am encountering is that although I have no problems with measurements and data logging per se, the PWM functionality of the VI appears to get 'stuck.' I have an oil circulation system; the oil is being heated by an uncontrolled source (friction) and I wish to maintain the oil temperature in the main chamber at 49 °C ± 0.5 °C with a small heat exchanger and 12V DC fan. The fan motor only posesses two wires, thus I am relying on an opto-isolated solid state relay to realise the PWM functionality. Some oscillation about the set point is fine and fairly unavoidable, due to the limitations of the test setup, for example, the flow rate of the oil pump. The following information will illustrate more clearly what I am referring to:

• I am using a cDAQ 9178, running LabVIEW 2024 Q3 64 bit on Windows 10
• Temperature is measured using K-type thermocouples and measurement data is acquired with an NI-9219
• The solid-state relay is controlled using an NI-9263, which in turn switches the fan motor
• The PWM algorithm is dependent on wait time inside a while loop, where the on and off times are determined by a) whether the loop is even or odd, and b) the error arising from the difference between the temperature set point and the measured value (the PWM functionality is dependent on only one of the three temperature measurements), multiplied by the gain and the period. The frequency is proportional to the duty cycle to provide a more effective 'ramping' behavior.
• Maximum PWM frequency is 2k Hz
• Measurement data is acquired at 100 Hz. I am currently experimenting with different values for the buffer (samples to read); perviously it has been 50, 100, and 20.

The main issue I am experiencing can be seen in the attached image of the time-series plots, where I have plotted measured temperature vs time and duty cycle vs time. Mosty, the PWM functionality works fine, until it seems to pause, until after which it reacts suddenly causing a large spike in temperature. Any help would be greatly appreciated.

Regards

[Kevin_Price]

I'm not using a new enough version of LabVIEW to open your code.  Can you back-save to something like LV 2020 for those of us who often deal with older codebases and delay our LV upgrades?

-Kevin P

[JammyHam]

Hi Kevin,

No problem, attached is a LV2020 compatible version.

Best regards

[Kevin_Price]

What you posted is only a loop for temperature measurements and logging.  Given the reliance on a DAQ Assistant, an Express vi for logging, and local variables for data sharing, I suspect you're going to need more answers and training than I can give in a couple paragraphs.

Look into the online training and spend time with the shipping examples -- run them, examine them, make small mods (but always "Save As..." to a new location!!).

If you post the frequency measurement code, I might be able to offer some suggestions to get you started.   The first one will be NOT to use the DAQ Assistant.  The second one is likely to be: start the task once before the main loop, don't stop it until after the loop terminates.

-Kevin P

[JammyHam]

Hi Kevin,

Thanks for your reply. Please check the block diagram and zoom out when you do.

Best regards

[Kevin_Price]

Ok, I zoomed out, scrolled around and found the other loop.

There I saw many more local variables & their race conditions.  It's awfully messy and looks overly complicated for what you're trying to do.   I have suspicions about your decision to set frequency proportional to duty cycle -- something about that just doesn't sound right.  Note that the duty cycle seems to get "stuck" near 0 during the time period in question.  

I've known of 2 kinds of PWM schemes:

1. Constant frequency, variable duty cycle.

2. Constant OFF time, variable ON time.  This makes frequency vary *inversely*  with duty cycle -- a longer ON time makes a larger duty cycle which makes a longer period which makes a lower frequency for the switching loop.  

-Kevin P

[JammyHam]

Hi Kevin,

Thanks again for your reply. In summary, you raised the following points:

• The DAQ Assistant VI is bad, wire correctly with DAQ mx create task, create virtual channel vi's etc.
• The loop for PWM functionality is, as it stands, unnecessarily messy - try to clean up and simplify.
• Proportional frequency control could be problematic, try without this functionality.

Please corrrect me if I have misinterpreted these points. Beyond these, do you have any other suggestions regarding the simplification of the PWM algorithm? Fundamentally I have the following:

Duty cycle (%) = (Measured temp - Setpoint) * KP_temp (this is forced between 0 and 100 %)
Frequency (Hz) = KP_freqency * Duty cycle (this is forced between 0 and an upper limit determined by the switching limit of the relay, in this case, set to 2 kHz)
Period (ms) = 1000/Frequency

ON time (ms) = (Duty Cycle / 100) * Period

OFF time (ms) = ON time - Period

5 V goes to the relay IF Duty Cycle > 0 AND loop == even, for a period determined by the ON time, OR Duty Cycle before forcing > 100 %

ELSE 0 V goes to the relay for a period determined by the OFF time.

Best regards

[Kevin_Price]

I think you understood the main points I made.  Another very important point I didn't go into details about are the "race condition" issues that arise when you use local variables instead of wires to get data values from one area of code to another.

Have you ever implemented feedback control algorithms before?   They can be tricky to troubleshoot on hardware because normally-useful tools like "highlight execution" can't be used to follow the dataflow.  And they can be tricky to troubleshoot away from hardware unless you can put together a decent model of the hardware's behavior.

Do you have a cDAQ digital output module that can operate your SSR?   A much better possible solution would be available if you ran a counter task whose duty cycle you can vary on-the-fly.   (Note: you might need to write both duty cycle and frequency at the same time, even if the frequency is always the same value.  Kinda obscure reasons...)

As part of troubleshooting your existing setup, I'd recommend that you use a Chart indicator to show a time history of your ON and OFF times.   I have a suspicion that your code may not guard against those times getting long enough that significant system response may be happening while your code is stuck idling at the Wait node.

    (This kind of issue would be eliminated with the use of a continuous counter task and digital output module.)

-Kevin P