IF loop issue

[cch1955]

I have been trying to debug a program and having odd results. Many wasted hours.

In testing I commented out the IF and the ENDIF of a loop but wanted to force the THEN commands to execute without the loop. here is the section of code:

'START START SKIP, BEGIN LOOP

'IF HSCPV[2] <= (S#_STRT_SKP_1 / D#_IN_PER_CNT) THEN      ' check to see if we are done with this part

   SETIO BLAST_1      'turn blast on begin skip1
   SETIO IN_STRT_SKP   'set relay to indicate in start skip now

'ENDIF

If you comment out the loop as I show here, the SETIO lines will remain highlighted as if they are now going to execute as if the IF loop were not in place. THIS IS NOT THE CASE, THEY ARE INACTIVE !
If I move the two SETIO lines out side of the commented out IF loop, they program functions as you would expect.
If program code is inactive, I should be shown by removing highlighting and color from the code.

Please consider this issue and change in a bugfix update. Possibly this ha been updated already?

[garysdickinson]

You may want to think about what you are doing in the IF part of the problem:

IF HSCPV[2] <= (S#_STRT_SKP_1 / D#_IN_PER_CNT)
[/font]

You are comparing a 32 bit signed integer, HSCPV[2], against a floating point value as the result of the division.  The TBASIC compiler CANNOT directly compare two different types of values.  The TBASIC compiler will have to promote (convert) either HSCPV[2] to a floating point value or convert the floating point result of the division to an integer.

In either case you are comparing apples to oranges as the two types of numbers, float and integer, are not interchangeable.   Floats and integers have limitations as to the range of values they can represent and to what accuracy they represent the values.  Remember, in most cases, a float is an approximation of the actual value.

I would stick with integer variables on both sides of the equation.  If you want to calculate 99% of some  integer, multiply it by 99 and then divide by by 100.  Be certain that you multiply first, then divide!

Another thing to consider is that HSCPV[2] will be treated by TBASIC as a 32-bit signed value.  If you are using this counter to count stuff that only increments.  HSCPV[2] will count up to some really big positive number and on the next count the value will become a really big negative number!

I'm a little concerned about your description of an "IF loop".  In what way does an IF statement "loop"?  I think of FOR/NEXT and WHILE/ENDWHILE as looping constructs.  It is a next to impossible to get code to run in a loop with only an IF statement unless you add in a  GOTO.

IF you comment out the IF and the ENDIF the code that is left will execute.  If would not trust the color coding of the simulator as proof of anything.  Set a variable or use a break point.  Better yet run the code on real hardware.

I'd also restart your computer as the Java code that the simulator is written in can fail in real interesting ways.  There may be nothing wrong with the code other that the simulator has gotten lost.  This happens to me all of the time.  It's one of life's little frustrations.

Gary D.

[cch1955]

Appreciate your response Gary on my issue. I understand the issues to do with total accuracy and capacity of the different types of variables. In this application the code produces reliable results within the requirements of the application at hand.

The use of the floating point data type greatly simplifies both coding and debugging code without the tedium of integer conversions. The TBASIC will produce an accurate conditional test of different data types. Each application has to evaluate the effects of rounding issues and the need to accommodate tracking errors.

The issue I’m concerned with is that if you comment out the IF conditional test line and the closing ENDIF, the code that was to be executed after the THEN  should function as if the IF test were never in place.

The current complier leaves the code highlighted in the custom function editor and gives the every indication it is standing alone and functional when commented out as I indicated, when in fact that code is dead.  I believe this is a bug that needs to be fixed.

I am running 7.03 build 6 on windows 7 64 using the ancient Java version suggested by Triangle.

Thanks.

[garysdickinson]

I still don't quite understand your problem.  

I'm running 7.03 Build 8 (may not be actually released, yet)  and an equally old version of Java on a Windows 7 64 bit.

I've attached the test file and the code runs in the simulator and on real hardware (Fx2424) and in both cases sets 2 bits that I mapped to OUTPUTs.

How does this code behave for you? Does this code run in the simulator? Does this code run on real hardware?  

Gary D.

[support]

If you comment out the IF line and the ENDIF line, the codes in the IF block (calling it a BLOCK is a better way as it is not a loop) should still execute as illustrated by Gary's example. I downloaded Gary's example and the code between the IF and ENDIF continue to run correctly when "Test" input is turned ON.

You may like to check your code again. Is this custom function being called from another custom function? Perhaps the function was not called at all?