compound boolean logic scripting

[Jason Stallard]

Greetings!  I would like to pick everyone's brains for how one might implement compound boolean logic scripting in LabVIEW ... specifically LabVIEW-RT.

My application is an in-vehicle data acquistion and logging setup.  The app is setup so that the user provides a configuration file which is the list of channels (GPS, DAQ, CAN) that they wish to record...so this means there isn't any hard coded variable but an array of clusters built from the configuration file.

A mode of operation is a 'trigger' mode, which means the logger doesn't record anything until a trigger has occured.  Currently the user provides a simple comparator (0=lessthan, 1=equalto, 2=greaterthan, else=none), and the trigger value.

The users want to be able do compound conditions like PARAMETER <= x OR Parameter >= y ... possiblly even between 2 different data points like PARAMETER_A <= x AND PARAMETER_B >=y.

Any comment, hints, tips, suggestions ?

Thanks!

Jason Stallard

[AESulzer]

Is this triggering occurring in hardware or software? If the triggering is in hardware, then what is the hardware that you are trying to trigger? If the triggering is in software, then you can simply use some of the conditional structures (Select function, case structure, etc.) and boolean logic functions (AND, OR, etc.) in LabVIEW to accomplish the conditional logic.

Kind Regards,

[Jason Stallard]

Thanks for the reply.  It's software triggering based on user configuration.  I think I've figured out how I'll be doing it, but will require me to limit the user somewhat...I'll allow them only a few (1-4) conditionals to check, and will not allow them to use parens or brackets to avoid order of precedent.  This will actually be a bit more elegant than what they have now since they wont have to provide an enum for the conditional, and they'll be able to do condition checks between 2 different parameters.  When the configuration file is parsed, I'll search for the index of the parameter since I store all data in one large array...so the config file will look something like...

[Triggers.ini]

Fan_Speed < 300 AND Intake_Temp > 500 OR Exhaust_Temp >800

So in code I'll have an array of clusters which includes the index of the parameter, the condition [<=>], and the boolean operator.  It will simply go from left to right...so for example:

Fan_Speed < 300 AND Intake_Temp > 500 OR Exhaust_Temp >800

=TRUE AND FALSE OR TRUE

=FALSE OR TRUE

=TRUE.

Any comment on this approach ?

Thanks!

Message Edited by Jason Stallard on 01-16-2006 08:40 AM

Message Edited by Jason Stallard on 01-16-2006 08:41 AM

[AESulzer]

Jason,

I think the approach sounds great! Excellent job coming up with a solution on your own.

Kind Regards,

[mfitzsimons]

Put a post up if you get it working.  This is one of LabVIEW's few weaknesses.  I have wrote a system that uses text to drive a LabVIEW queued message handler.  It is not to hard until you get to conditional branching.  It supports whiles and ifs that once again is not impossible.  The real fun is nested statements.  Ifs and Whiles as deep as they want to go.  I gave up when it came to compound statements and told them to use another if.  It would be nice if someone came up with a good evaluate subroutine that supports compound logic.

Looking forward to hearing about your progress,

Matt

P.S. Text programming is in the dark ages in comparison to LabVIEW but sometimes it is nice to have a text script drive LabVIEW application flow.

[Jason Stallard]

I hear ya.  The big thing I was struggling with was that the user can define what they want to record so that the logging application is quite generic regarding the parameters.  It's not to difficult to give someone a script interface, but it's usually application specific and non-portable.

Here's my VI to do the boolean operations...I think I put in enough comments to explain what I'm doing...but if you have any Q's just lemme know...or if you have any suggestions of your own.  I'll re-post when I've got the parser done.

-Jason

[mfitzsimons]

Jason,

You code looks excellent, well written.  Correct me if I am wrong but I think there is precedence in evaluating the Boolean logic so scanning left to right may not work.  I looked at the default statements:

Test1 2 == 100 AND Test2 0 <= 5 OR Test3 1 <= 3

Evaluates to

False AND True OR True that evaluated correctly but Trigger is True

Shouldn't it be evaluated as: False AND (True OR True)

False AND True

False so Trigger should not be True?

Let me know what you think,

Matt 

Source:http://www.archivessearch.qld.gov.au/help/boolean.htm

Table 1 : Boolean Operators - Precedence Rules

Operator	Order of Evaluation
>( )	1st
>AND, NOT	2nd
OR	3rd

[Jason Stallard]

You're right.  I said something to that effect in the code comments, but the only oder this VI will follow is left to right, and it doesn't support negation(NOT)..the person writing out the quasi-script would have to keep that in mind.

My intent isn't to write a full-fleged interpreter, but give the user more flexibility in how they define a 'trigger' event...and this is an in-house application...were it for public comsumption, I'd definitely try to put in full support for boolean operations....but then again it is quite a challange.

[Underflow]

Jason,

It's interesting how often the problem of text-based scripting to drive LV pops up.

I had a problem with similar properties: given a set of data and an arbitrary set of rules, substitute data into each rule and see if it evaluates to true or false.  This is used to provide directions from engineers to operators on how to perform failure analysis and recovery, without the engineer needing to be present.

The problem that I ran into turns out to not be in evaluating the data and rules, but in parsing the arbitrary input equation.  There just isn't any general way inherent to LV to parse an arbitrary text language into an intermediate form (like a postfix expression or an abstract syntax tree).  A relative lack of recursion makes it a little more painful as well.

I can't release my code, but it essentially had three parts:
1.  In a given rule in infix form (variableA<7, for instance), perform macro replacement.  Essentially, substitute values for variable names, perform file lookups, etc.
2.  Transform the substituted infix equation into a much easier to deal with postfix equation.  (Thanks to Mike Porter for this suggestion as well).  This step can be non-trivial.  I'm currently building an editor that will build equations more easily, sparing my engineers much pain.
3.  Evaluate the postfix equation for a single true/false result.  This algorithm should be available in many books, but I adapted the one from an earlier version of this book:
http://www.amazon.com/gp/product/0201702975/qid=1137608429/sr=2-3/ref=pd_bbs_b_2_3/103-3337903-1387046?s=books&v=glance&n=283155
It also contains a short description of a stack-based parser that's fairly easy to implement for step 2.

Anyway, there's my 2 cents.  Maybe someday I'll find time to write that LV based parser generator to "simplify" all of this 😛  Good luck!

Joe Z.

[mfitzsimons]

Jason,

Your code looks great and we will let someone else design the complete evaluator.  I think what you have is fine for your application.  You just need to sort the ANDs and ORs then evaluate the results.

Matt