oxyGEN vs. Python graphs yield different results

[lucasshangAV]

Hi,

I am currently writing a simple program which switches the pressure off in channel 1 and turns the pressure on in channel 2 at the same time.

I used the same parameters in oxyGEN and in Python (default parameters of response time for both pressure = 2 and flow rate = 5). I've noticed that there are more parameters on the oxyGEN interface that I haven't found in the Python SDK, such as the pressure increment option. My aim is to get a graph using Python that's close to what's obtained with oxyGEN (without a gradual increase rather than a spike).

I've attached graphs of the different versions obtained :

oxyGEN :

Python :

[Ygor-Oliveira]

Hello,

Can you share some more details of your setup, like which instruments you are using and what commands you are sending them? Or share the Python script you wrote? OxyGEN uses the fgt_SDK internally, so it should have the same results if the same parameters are used. The parameters that are only in OxyGEN are for advanced functionality implemented directly in the UI, like waveforms and channel coupling, or parameters that only make sense in the UI, like the increment, which is the amount by which the command changes when you click the up and down buttons. For a simple preprogrammed step command, these parameters shouldn't make any difference. In your Python graphs, it seems that there is a delay between the pressure and flow rate, which causes the overshoot. But it is hard to tell, since the two graphs seem to have different time axes. It would be easier to look at the raw data in CSV.

Best regards,
Ygor

[lucasshangAV]

Hi,

Thank you for the quick reply.

In my code, I use a binary array (ex : 10010011), where each number corresponds to a channel and for which a 1 corresponds to an open channel and 0 to a closed one :

for sensor_index in range(0,len(binaryArray)):
if(currentArray != binaryArray): # only updates flow rate regulation if counter is updated
if(binaryArray[sensor_index] == 1 and counter < pow(2,nbChannels)):
fgt_set_sensorRegulation(sensor_index, sensor_index, 20) # SETS FLOW RATE TO 20 FOR CHANNEL INDEXED WITH SENSOR_INDEX
else:
fgt_set_pressure(sensor_index, 0) # SETS PRESSURE TO 0 FOR CHANNEL INDEXED WITH SENSOR_INDEX

This is the part of the code which regulates the state of the channel, and is contained in a while True loop, counter is incremented by user input.

Here is the raw csv data :

Python_OxyGen.zip

I wish to have the smallest delay possible when changing states from 0 to my set flow rate (20 microL / min) and I wonder how to set the response times in order to achieve this.

Could you explain what the response times correspond to ?

Cheers,
Lucas

[Ygor-Oliveira]

The flow rate response time is an expected response time in seconds in an ideal setup, so the larger the value, the more slowly the flow rate will increase. It is mainly useful to force the regulation to go slowly when there is a delay between the pressure and the flow rate (e.g., due to elasticity in the microfluidic chip, or non-Newtonian fluids), to prevent instability. In most cases it can be left at the default value, which is the fastest it can go.

The pressure response value is interpreted differently depending on the type of controller, but for the MFCS you should basically set it to a value close to the volume you are pressurizing in milliliters. It does not have a huge impact on performance. The MFCS is unfortunately somewhat slow when depressurizing, because its air leak is passive.

I think you can leave the flow rate response at its default value, and experiment with the pressure controllers in open loop (i.e., set the pressure directly instead of the flow rate) using different pressure response values to see what is the fastest they can go, to have a better idea of the performance you can expect from the system. If possible, you can try to reduce the volume to pressurize by using smaller reservoirs or filling them more, or use shorter tubes between the MFCS and the reservoir.

In the CSV files you attached, I don't see much difference between the Python one and the OxyGEN one. They don't correspond to the images from the issue description. In both files, the Flow Unit 2 reaches steady state in 2-3 seconds. The OxyGEN one also shows a step for Flow Unit 1, which is slower, likely due to a larger resistance to the flow or a larger volume of air. There is no pressure overshoot leading to saturation of the flow sensor like in the first image. Is this a recurring problem, or did it happen only once?