parallel timing loops. Do I want to do this?

[mike72903]

I'm writing an application which communicates to a ASCII based instrument using VISA and the instruments comm protocol.  A driver does not exist for this particular instrument.  One of the requested capabilities is to have multiple scans individually enabled or not.  The scans will be of different channels and at different periods.  The time intervals involved are slow as the instrument multiplexes up to 100 channels through one measurement board.  For example scan 1 might be every 2 seconds and read 20 channels with a second scan running every 10 seconds on 50 different channels.  I understand that timing will not be accurate as one scan will cause a delay in the other(s) and thats fine.  Being a relative new Labview programmer I had started to do this using multiple while loops but just discovered the timed loops.  Is it okay to have multiple timed loops running in parallel?  Right now I have two timed loops in a case structure that is enabled by a boolean to start scanning and locals of that boolean in the loops to exit them.  Other booleans enable or disable the actual scan and parse modules so the timed loops are always running, just not doing anything if the scan associated with that loop is disabled.  I'm guessing this might be bad programming practice. I assume i will have to put any further processessing of each scans data in it's individual timed loops. I have attached an example of what I'm doing and would appreciate any comment as to this being a proper method to persue or if I need to change course.

The attachment vi doesn't appear on the preview post so it may not be present here. 

[mikeporter]

A little more info... While this acquisition is going on what will the user interface be doing? Displaying results as they are acquired? Controlling the acquisitions in some way like enabling and disabling channels?

How do you see the process working from the user's standpoint?

Mike...

PS: This may sound off-topic, but trust me, it's not.

[mike72903]

Hello Mike, thanks for the reply.  After the data is acquired, some Mx+B or other simple formula are applied to some channels.  Other channels, particularily those measuring thermocouples are sent from the logger already converted so no processing is required.  There will be some limited 'out of range' checking on some channels and if found out of range that data's display will be highlighted in some way.  Data will be displayed in two or more arrays or tables, probably on different pages of a tab control.  The operator will be able to select channels for sending to a chart control that will act as a strip chart recorder.  Haven't done a lot with chart/graphs yet so have that to look forward to    Data and/or the chart will be saved or printed on demand, or perhaps triggered by some data condition. 

This portion of the program will be a general purpose data acquisition program set up for our particular needs.  All the loggers channels will be individually programmable by the operator before scanning begins (logger eu and any math) and the operator will be able to select which channels will be scanned and at what intervals. The channel and scan programming will likely be on a seperate tab page.  There are 100 data logger channels available to each operator.  It takes aound 5 seconds for the logger to scan all 100 channels and transfer the data via RS232, but the operator may only be scanning 1 channel at a minimum time interval in some cases to see fast (for us) changing data.  I will need to have a 'logic triggered' scan where a scan of a block of channels is triggered by a  "trigger channel". The trigger scan would be caused by the trigger channel exceeding a min/max setpoint or a boolean comparison like a contact input.

In addition to the general acquisition/display capability, some dedicated test procedures will be run.  When these tests are run the general acquisition portion will not need to run so it can be disabled.  These tests are run over time with some minor control through output relays occur.  These output relays are on a seperate IO board also RS232 controlled.  Various reports and files will be read and written during testing/acquisition and a custom screen to display data will be provided for each test. It's possible these dedicated tests will be written as seperate programs perhaps callable by menus on the acquisition portion.

Well now you know about as much as me about how this program is going to evolve .  thanks for helping, hope this is the type info you were requesting.

Regards, Mike

[mikeporter]

Yes this is helpful, but a couple more questions: Where are you going to get the system's setup information from and what do you plan to do with the results data? Specifically, are the hardcopy reports the end of the road or is any of this data of archival value?

Mike...

[mike72903]

Mike, the hardware systems setup information is read in from a default file at program start.  It will be displayed on a programming page where the operator can change the channel programming or scan setup.  Changes can be manually saved but on program exit the last setup will always overwrite the old setup file automatically.  So, the last hardware setup is the default on start. 

Not 100 percent sure what your asking, but any hardcopy reports would be printed/saved and would not have to be recalled back into the program if that is what you mean by archival value.  Of course the reports are of archival value for our company.  Generating a report does not necessarily 'end the road' as far as the program continuing to run. It is possible that a series of tests will be run, each generating a report, but I don't anticipate the necessity of the running program accessing previously saved reports.  I anticipate using the report tools for writing to Excel templates.

Regards, Mike

[Daniel_E]

From your VI, you are not doing anything "wrong".  Only thing that might be better is having two state machines.  If you don't know about state machines, you can look at the LabVIEW template by going to File >> New >> VI >> From Template >> Frameworks >> Design Patterns >> Standard State Machine.  As search NI.com for state machines and you will find even more information.

Hope this helps!

Dan

[mikeporter]

Sorry for the delay in getting back with you but I was looking at what you posted and putting my thoughts in order.

From your description, the basic architecture I would implement for this application would consist of two major components: 1) an event-driven user interface that handles all the interactions with the operators; and 2) a standalone test engine that runs in the background (hidden) as a separate process. In addition, you will want to create a small simple VI that serves as a splash screen for the application and launches the two main components.

The test engine would incorporate the serial IO. It would get its list of channels to read from a functional global that is maintained in the user interface. It sounds like all the sample intervals are in multiples of whole seconds, is that correct? To simplify the code, the array of channels to be read would be an array of clusters where each element contains whatever addressing or identification is needed to select a particular channel, an interval and a timestamp. As the test engine indexes its way through this array it extracts the timestamp and compares its value to the current time, if the difference is greater than the interval, it does another reading. The results of this read are written to another functional global for communications back to the user interface, and the current timestamp updates the timestamp for that channel in the channel list.

The user interface would populate the channel list functional global and read the data functional global. In terms of its basic design I would avoid tab controls as they tend to complicate code and recently have been the source of a couple bugs. Instead, I would create the user interface as a general-purpose VI that serves to dynamically load screen into a subpanel on its own front panel. In this way you get a top-level that is very reusable and without the complications of needing to create one Vi that does everything. Instead you would have one plugin for editing setups, one for monitoring data, and so forth; and each of these plugins would be simpler because they are only having to do one thing.

Finally in terms of data management (test setups and saving of results) I would recommend a small embedded database. Having this resource sitting under you application will simplify everything else greatly. There are a wide range of free or no-cost database engines available ranging from products by commercial companies (OracleXE) to open-source packages such as FireBird, there's even a very basic database engine built into Windows that you can use. I can send you the drivers for accessing the database.

This is admittedly a rather broad-brush description but it should give you something to think about. I can walk through each of these areas with you in whatever level of detail is necessary. One thing to consider is that if you do this properly at the end of the process you will have a framework that you can then leverage to build other future applications.

Mike...

[mike72903]

Dan, thank you for your help and suggestions about state machines.  I will look into it

Regards, Mike

[Daniel_E]

My Pleasure!

[mike72903]

Okay Mike, I had to print that reply so I could study it.

It's odd you mention event-driven routines as that is what I was reading about this morning in the Travis/Kring book "Labview For Everyone".  I had just added an event driven loop to handle some of the booleans on my front panel to see how that worked when I got the NI email notification of your posting.

I'm not sure how I would incorporate a database but will look into that more.  The last time I had anything to do with a database it was playing around with dBase in the prehistoric age of the Osborne "transportable" computer.  Seems like yesterday.

Honestly, the depth and capability of LabView astounds me. I have been playing around with this and it's been a lot of fun. You have given me a lot to consider.  Before proceeding with this too far, I need to consider your very much more structured approach than I was entertaining.   So, it's back to square one, which for me is never too far.  Besides, it's always nice to be home again.

I see you are a prolific poster to this forum.  Not sure how you do it but I know many appreciate your efforts.  Please know that I do also.

Thanks again and Best Regards,  Mike (who remembers CPM)