Thermal Management for EV lab

[jonathancox]

Good afternoon

I am looking for advice on best practices/development schemes for a control and data acquisition system for someone relatively new to LabVIEW.

We have built a lab to simulate the thermal mangement systems of an electric vehicle inside a climate chamber (HVAC, battery heating, drivetrain cooling). There are physical models of the coolant, refrigerant and air loops in this lab. DAQ and control is done through a cDAQ 9172.

Here's a list of the sensors and actuators involved as part of this setup and how they interfance with the cDAQ:L

Sensors:

8 pressure sensors 

a few dozen thermcouples

3 flowmeters

3 wattmeters

Actuators:

4 electric expansion valves (stepper motors)

3 proportional valves (0-10V)

2 pumps (pwm)

3 VFDs (DIO for on/off and 0-10V for frequency)

3 heaters (4-20mA)

4 shutoff valves (DIO)

The end goal is that we can change thermal configurations via the shutoff valves and then run a drive cycle by modulating the heater load over time (via simulation data read from a spreadsheet).

If one had to control this amount of actuators while acquiring and storing data, is there any developement scheme that comes to mind (producer/consumer). I'd love a bit of insight from those more experienced on how to proceed with a project of this size. This is essentially a benchtop air conditioning system with data acquisition.

I have created a VI already that allows each of these to be controlled and read directlty, in a single while loop. This seems like an inelegant way to proceed with the more automated part of the project. I'd appreciate any insight.

Thanks very much

Jon.

[B_Strange]

I thought about trying to explain how I'd do it but realized that it would probably be easier to create an example. So, attached is a zip file containing a project with a skeleton program. It would probably be classified as a producer/consumer but it uses a functional global to pass data. Each major function (UI, data acquisition, instrument control, and datalogging) has its own loop:

   -The UI loop displays acquisition data from the FGV and inserts control data into the FGV when necessary.

   -The data acquisition loop simply gets data and writes to the FGV.

   -The instrument control loop takes control data from the FGV and passes it to the appropriate control device.

   -The datalogging loop reads from the FGV and writes to file.

An additional loop for automated test functions can be added as well. I would suggest making it a state machine which can modify control values (by writing to the FGV) while adhering to sensor data (by reading the FGV) and custom time constraints.

I'm curious to see how others would do this. It isn't my first rodeo but I am far from what you might call ... accomplished.

On a side note: Has there ever been any sort of "Architecture Games" where someone presents a scenario (such as in this thread) and folks can contribute a solution to see who has the best one?

[jonathancox]

Thanks very much! I'm going to have a look this afternoon