Split program in smaller ones

[johnking]

My LB program is used to read data from the serial ports from measuring equipment.

The program is actually divided in 9 parts

1. Initialisation

2. user input

3. calibration of the instrument

4. measurement 1 (voltage)

5. measurement 2 (frequency)

6. measurement 3 (distortion)

7. saving to results to a file, after that go back to 1

8. when needed testroutine to test the communication with the instrument

9. when needed testroutine to test the integrety of the results file (7)

Allthough I used [branchlabel] , the program is becoming so long it is a lot searching everytime
Is there a smart way to split it and save it up in separate sub-programs/modules/routines and call a sub-programs/modules/routines when needed ?
Or any ideas how to change it in a more comprehensive program.


 

[Rod]

There are two main methods. Both are contained in a single program which is much easier to manage and to run and share information, input and data.

The first method is to use [branchlabels]. Each [branchlabel] sits atop a code block that typically ends with a wait or return. So the code block is self contained. The second method uses Subs, again each Sub contains a block of code that typically provides one service to your program. You can of course also have Function code blocks.

Now if your code is segmented like this you will find functions at the top of the IDE to hunt down code. Click on the Jump To icon, you will get a list of your code blocks and by clicking you can navigate straight to the code block. Check also Find/Replace which will repeatedly find or replace code within your program.

I would not recommend splitting your program. There are few memory issues, size does not matter and you avoid having to manage conflicts like which program gets access to the device. Only one program can have access at any one time.

[johnking]

Thanks Rod, I wrote 'remarks' but actually meant [branchlabel] (changed it now for clarification). The listing is allready full of branchlabels. But I added extra branchlabels at the start of each 'module' which start with asterix-es. That way I can at least identify easier the different modules.
I see the point working with seperate programs, will possible also cause problems with variables.

[brendan]

Is your program continuously reading the serial port? Have a [main] routine that acts like a register with a SCAN loop & SELECT statement. Assign each part 1..6 a function variable for the SELECT statement within the SCAN loop.
Each SELECT CASE will branch to a sub routine. Sub routines for each of the functions will make for easy debugging, updates, viewing in the LB IDE & general code chasing. Variables can be passed between subs and changed within subs using BYREF. This should ensure your program doesn't get hungup in a [branchlabel] WAIT statement. They should always go back to the [main] fro continued scanning.

[main]
SELECT 
    CASE function1
        CALL function1
    CASE function2
        CALL function2
END SELECT
SCAN
GOTO [main]
--------------------------------
sub function1 volt

end sub
--------------------------------
sub function2 freq

end sub
--------------------------------

[brendan]

Another option is to make Token files. You can pass variables to them via the CommandLine$ statement or an external file, like an ASCII data file. Great for modules and if you need to update.

[Rod]

Full of branch labels? There in lies the problem. Do not put a branch label above another branch label without code in between else the .exe will fail, a known bug. Use branch labels sparingly and head up a code block that runs to completion with wait or return or allow it to fall through to amother sequential code block. Look on branch labels as pseudo sub names. They should wrap complete routines that stand alone or can be called repeatedly. Don’t view them as rem statements/labels

Also .tkn still gives you the port conflict so a single stand alone program is by far the best choice.

[johnking]

Ok, thanks Rod. Although I can make an EXE file, I can see the possible problem of putting branch labels above another branch label without code or using them falsely as sort of REM statements.