Labview Application notes (rev engineer Labview design):

[ralphBellofattoSTX]

This issue will provide notebook space for attempting to decode the labview application.

For me this is starting with absolutly no experience with labview, so expect a bit of stumbling around, but hopefully over time, there will be enough information as to any software control app needs to do.

[ralphBellofattoSTX]

Downloaded a trial copy of labview from the web link

NOTE: linux and mac versions are not available via this link unless you already have a service contract. I was able to contact their sales support and was able to snag a copy for both mac and linux.

However, Currently labview is not supported on the most recent mac os (catalina) and it is only supported on linux centos, SELS and redhat. Not ubuntu.

Supported Operating Systems You can run the LabVIEW for macOS/Linux installer on the following operating systems:

(macOS) macOS 10.13 or 10.14 (Linux) openSUSE LEAP 15.0 openSUSE LEAP 42.3 Red Hat Enterprise Linux 7.x Red Hat Enterprise Linux 8.x CentOS 7 CentOS 8

Also while labview should work in a vm. Labview support currently says it should work, but they won't support it if the user runs into problems.

So far, i have it working on a windows machine and using remote desktop to connect with my mac laptop.

Will try to install on centos in a little bit to see what happens there.

[ralphBellofattoSTX]

program inputs:

static inputs (calibration, etc)

Pressure control and valve control:

[ralphBellofattoSTX]

screen (UI) views: Three tabs, Clinical/setup/advanced

There is also an advanced button (don't know what it is connected to yet).

[ralphBellofattoSTX]

Outputs (valves) (as named in labview)

• air
• 02
• inhalation
• exhalation

Inputs (sensor):

• O2 sensor
• Pres -- (pressure in the reservoir manifold)
• Psys -- (pressure in manifold closest to the patient).

[ralphBellofattoSTX]

Left block seems to be most associated with static setup and the active graphs, although it might also have the pressure sensors...

Trying to find what a sensor input looks like in labview.

The right large block appears to have a master loop attached.

[ralphBellofattoSTX]

the master loop on the left:

is set to loop at 1Khz.

[ralphBellofattoSTX]

going back to see if there is some enlightment on how to go around labview: https://www.labviewmakerhub.com/doku.php?id=learn:tutorials:labview:basics

[ralphBellofattoSTX]

Using the run + the lightblub, we can singlestep the model

and follow the signal flow.

[ralphBellofattoSTX]

this module: Sub-Calculations.vi appears to be the module that calculates the 02%,

It appears to be openloop, in this case, i'm not seeing where it takes the 02 sensor as an input...

This is two levels dep, from the master level:

the timing control block: Sub-TimingControl.vi

[ralphBellofattoSTX]

single stepping into: Sub-Calculations.vi I probed the outputs and got these values:

exiting this module into its parent we see:

[ralphBellofattoSTX]

when the Sub-Calculations in motion we see:

The respiration rate translates to the Nloop value (length of the respiration loop). Ngas -- total ngas cycle. Nox and Nair are the part of this loop during which the nox and air valves are open. NOTE: at times both values are open (which is interesting)... Nair and Nox cycle both during the inhaliation cycle and the exhailation cycle.

the following stage (valve control) controls when the valves are actually open, closing them when ptarget is reached or when the inhalation cycle begins, which ever is first (i think)...

Cuts off the Valve output when Pres >= pTarget.

[ralphBellofattoSTX]

documentation from google drive: https://drive.google.com/drive/folders/1vhFovHhYe0O6wtgYA6j-EA_gogn7zqzi

Cuts down some of the noise.

[ralphBellofattoSTX]

analysis from David Fortin fortindc@gmail.com :

Hi Ralph: I got some new freelance work on Monday so I only had yesterday and a bit of today to work on it.

To try and figure out what is going on, the only way is to reorganize the code into more logical blocks and also make it more readable so that is what I did. The zip file contains a png image of the main vi hierarchy, a functional description document meant to be used as a guide to create a program in some other language and the code that I reorganized. Note: Be careful not to open this project at the same time as the original project as they both have vi names that are the same but have been changed. The second of the two programs opened will be substituted for the first program opened and if you save it, it will refer to the location of the vi with the same name in the first program. ie: It will be a mess. Always remember to shut down LabVIEW in between when opening one or the other but never both at the same time. Keep the zip file as backup just in case :)

I am thinking this was written by a grad student as I have worked on code like this before. There were controls that had no input but were only reading values which means they are actually indicators. In fact there were a lot of things that didn't follow LabVIEW programming conventions. I tried to address as many as I could. As much as I could, I put controls that trigger some change into an event structure, which is the while loop just above the main loop. The way it works is that when a value changes for a specific control, it fires the event and whatever is in the event structuregets executed.

The error chain was split off into two in the original while loop. Presumably to have the digital outputs fire around the same time as the analog input. Only problem there is that there was a data dependency between inputs to the DIO driver and the outputs from the AI driver. In this case there is no point in splitting the error chain as it is sequential and not parallel in how it was programmed so I combined the error chain into just one. I think the flow is much better but it is still a bit of a dog's breakfast. I left the calculations unchanged but have cleaned them up so that they were more readable. Also, it should make a lot more sense in the overall program where they are executed.

If you look at the DIO Driver, it is a case structure inside which is kind of equivalent to a set of functions (methods) specific to doing digital IO. There is a while loop with a terminated shift register. The purpose of that is to hold and pass data between function calls on the main block diagram. This way all the methods and properties of the digital io stuff is contained within a vi "object" and not strewn all over the main block diagram. It makes it easy as well to just plop the driver into any program and start using it, if you wanted making it reusable. You can also test and verify components separately. The functions are called by attaching an enumerator to the driver vi on the block diagram (it is below and slightly to the right") and selecting the function (method) you want to use. Most drivers operate with some standard methods like for eg: init, config, write, read, end but can be more sophisticated than this. You can also have these "objects" or labview 2 style globals (LV2Gbl) store and operate on data within the program. There is some work to be done still in trying to create a functional description but at least the problem is more tractable. Errors in reorganization should be very small as I was pretty careful.

I put together a functional description document and entered the main program (ie: Top Level) details in order of how the program flows. These are the functions and object function calls, cases, switch statements etc. This document was made with Libre Office. It should be able to open in Windows but if not, you can download Libre Office for Windows free here https://libreoffice.en.uptodown.com/windows/download

Main Program Flow 1) Initialization Section 2) Configuration Section 3) Main Acquisition Loop Section 4) Event Structure Loop Section 5) Exit Cleanup Section

Objects: LV2 Style Globals - breaks down all of the Objects and their function calls internal function calls in order 1) Analog Input Driver Object 2) Digital IO Driver Object 3) Psen/Psys Parameter Object 4) Calibrate Pressure Object 5) Data Buffer Mem Object

Functions 1) Timing Control Function 2) Value Logic Function 3) Function Other1 - other functions that need to be specified in this document. I have provided a template. 4) ...

Cases Case Structure - This is a main diagram case. You could roll this into a function if you wanted but I left it this way.

Switch Statements Update Display Switch Statement - This is the only one and is used to decide which display items get updated depending on selected tab.

Event Structure Loop Section - Each event is listed with a template for adding procedure/function calls within.

This should be adequate to get the ball rolling for someone needing to convert this program. Although, IMO it is way less work just to write the program in whatever language while looking at the block diagrams than to write a specification in detail. Shift registers inside of Objects can be considered as variables internal to the object.

On that note, I may be busy for some time now unfortunately (it was fun to do) as I have freelance work that I need to do as it puts much needed bread and butter on my table. This pandemic isn't doing us any favours that's for sure. I don't think I will be able to continue as I had thought originally. My apologies but I hope this can help you move forward more swiftly. I tried to get as much done as I could in what little time I had.

Thanks, Dave :)

[ralphBellofattoSTX]

@stephmusinsky The labview code can be found here: https://drive.google.com/drive/folders/13Hd2DWp4qFouH4aUFbl0Jl-0fOQhSAF7

There is some code documentation here: https://drive.google.com/drive/folders/1vhFovHhYe0O6wtgYA6j-EA_gogn7zqzi

Here are the doc files from david. Ventilator.zip

You probably want to do a combination of this analysis AND looking at labview itself.